Hi Raaed Almohlsi,

The UBR registry key located at HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion can easily fall out of sync during an aborted update sequence, making it an unreliable metric for patch compliance on affected machines. When an update stages, the system pre-emptively increments certain WMI classes and registry values. If the installation fails at the last moment and the subsequent rollback process crashes, these values remain artificially elevated, tricking your endpoint management tools into reporting a successful installation. For your enterprise fleet, querying the LCUVer registry key or directly retrieving the file version of C:\Windows\System32\ntoskrnl.exe remains the only architecturally sound method to verify the true patch state.

The 0x800F0922 error indicates a critical breakdown within the Component Based Servicing engine. The update correctly unpacks its payload into the component store, which is exactly why standard integrity checks report no corruption and the package transitions to the staged state. The failure occurs during the finalization phase when Windows calls upon advanced installers to execute complex environment modifications. If an advanced installer fails to provision a modern application, update the Secure Boot database, or write to the EFI system partition due to hidden disk space constraints, the entire transaction aborts and leaves the package trapped.

There is no supported method to forcefully push a staged package through a failed advanced installer, as attempting to bypass these critical environment changes would severely compromise operating system stability. To break this staging loop, we must parse the CBS.log file located in the C:\Windows\Logs\CBS directory to identify which specific advanced installer threw the fatal exception just before the rollback sequence initiated. Once the underlying environmental blocker is resolved, you must manually clear the stalled package by executing the DISM command-line utility with the Remove-Package parameter, targeting the exact PackageName of the staged rollup. Please provide the CBS log from an affected endpoint so we can pinpoint the exact failing component together.

Hope this answer brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

VP

Raaed Almohlsi

I assume the cause might lie in the specific combination of Features on Demand or Optional Features currently enabled on the operating systems of the affected subset. When a cumulative update applies via your internal WSUS server, the Component Based Servicing engine dynamically evaluates the target machine and only attempts to update the capabilities currently active on that specific installation. The 5,000 successful devices likely possess a standard, baseline image without additional features like the IIS Web Server, Hyper-V client, or specific localized language packs. Consequently, the WSUS payload fully satisfies their servicing requirements, and the patch finalizes without attempting an outbound connection to Microsoft's Content Delivery Network.

The 2,000 affected endpoints have these specific optional capabilities enabled. The WSUS infrastructure does not natively host the supplementary feature payloads required to update them. During the finalization phase, the advanced installers on these machines realize they are missing the necessary delta binaries for these optional features and attempt to reach out to Microsoft Update to acquire them. This connection is immediately severed by your enterprise policy block, causing the advanced installer to crash, abandoning the staged packages, and throwing the 0x800F0922 error code.

But to confirm this architectural split, please execute the Get-WindowsOptionalFeature -Online command on both a failing and a healthy device to identify the exact feature delta. To resolve the staging loop on the affected fleet without altering your global update policy, you can extract the official Windows 11 Features on Demand ISO to an internal network share. You can then script the repair using the Deployment Image Servicing and Management utility with the RestoreHealth and LimitAccess parameters, pointing the Source parameter directly to your internal share to satisfy the dependencies without traversing the internet.

VP

Hi Raaed Almohlsi

The root cause of this staging failure lies in your enterprise policy that blocks all Microsoft Update endpoints while forcing patch traffic through your internal WSUS server and ManageEngine. When a Windows 11 Cumulative Update applies to a system with enabled Optional Features or Features on Demand, the servicing stack must update the binaries for those specific features. Because the standard WSUS update package does not natively contain these supplementary feature payloads, the system attempts to reach out to Windows Update to acquire them. Since your policy explicitly blocks this outbound connection, the advanced installer fails to resolve the dependencies and crashes with the 0x800F0922 error, abandoning the staged files and triggering the rollback across your fleet.

To resolve this architectural bottleneck without compromising your centralized update management strategy, you must implement a targeted Group Policy exception. Navigate to Computer Configuration, Administrative Templates, System, and locate the policy named Specify settings for optional component installation and component repair. Enable this policy and check the option to download repair content and optional features directly from Windows Update instead of WSUS. This configuration securely permits the servicing engine to fetch only the missing feature payloads directly from Microsoft's Content Delivery Network, while keeping your standard monthly cumulative updates strictly managed by ManageEngine.

After allowing the new policy to replicate to an affected endpoint, clear the stalled package from the servicing queue using the Deployment Image Servicing and Management command-line tool as we discussed previously. Reboot the machine to flush the pending states and trigger the patch deployment again to verify the fix.

Hope this helps :)

VP

1. On Windows 11 25H2, UBR alone is not a reliable indicator of patch compliance, especially because 25H2 uses the same servicing branch as 24H2 and relies on an enablement package model. The context shows that Windows 11 25H2 devices can have complex update states (for example, XAML-dependent apps breaking after certain LCUs, and Known Issue Rollbacks via policy), and that the effective state of the system is tied to the cumulative update actually installed, not just a single registry value. The kernel (ntoskrnl.exe) file version and the actual installed cumulative update (via package state or KB level) are the reliable indicators of patch level. The LCUVer value and the kernel file version are therefore more trustworthy than UBR for compliance verification.
2. Error 0x800F0922 is a generic servicing failure code that can occur even when DISM and SFC report a healthy component store. In the provided context, 0x800F0922 appears in multiple Windows update scenarios where:
   • A package fails to transition to the desired state (for example, “Failed to be changed to the Absent state. Status: 0x800f0922” in Windows Server 2019 when the HTTP service is disabled). The fix there is to enable the HTTP service by setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Start to 3 and retrying the update.
   • Cumulative updates roll back late in the process due to problematic event channel or registry state, requiring deletion of specific problematic registry keys.
   In all these cases, the pattern is that servicing can stage the package but fails during a later phase (finalization/commit or removal), returning 0x800F0922. This aligns with the behavior described: packages in “Staged” state that never finalize. Even with a “healthy” component store, servicing can fail due to:
   • Disabled or misconfigured system services required by CBS/servicing (for example, HTTP service in the documented Server 2019 case).
   • Corrupt or inconsistent registry entries for event channels or update-related components that only surface during advanced installer phases.
3. There is a known issue in the Windows 11 25H2 servicing stream where updates installed via WUSA from a network share can fail with path-related errors and odd post-installation behavior. Specifically, Windows updates installed using the Windows Update Standalone Installer (WUSA) or by double-clicking an .msu from a network share containing multiple .msu files can fail with ERROR_BAD_PATHNAME and show inconsistent state in Update History. This affects devices that installed updates released May 28, 2025 and later and is resolved by updates released March 24, 2026 (KB5079391) and later. Before that fix, the supported workaround is to copy .msu files locally and install from there. Additionally, for Windows 11 24H2/25H2 there is a documented enterprise-only issue where provisioning with certain LCUs (for example, KB5062553, KB5065789) causes XAML-dependent apps (Explorer, Start menu, Settings, Taskbar, Search) to malfunction, especially in managed/VDI environments. This shows that 24H2/25H2 enterprise servicing has had complex, environment-specific issues, and Microsoft has been addressing them via specific KBs and Known Issue Rollbacks. However, the context does not describe a specific, named known issue for WSUS-delivered cumulative updates on Windows 11 25H2 that exactly matches the “Staged but never Installed with 0x800F0922 while Get-HotFix shows installed” pattern. Known issues around WUSA/network shares and XAML app provisioning are documented, and 0x800F0922 is documented as a servicing failure in other products, but there is no explicit statement of a 25H2 WSUS-only bug in this exact mode.
4. When a patch is in “Staged” state, the supported approaches in the context are:
   • Install a newer cumulative update that contains the fix for the underlying issue. For example, the WUSA/network-share failure is resolved by installing KB5079391 or later, which removes the need for workarounds.
   • Use Known Issue Rollback (KIR) via Group Policy where Microsoft has published a special policy for a given regression. For Windows 11 24H2/25H2 and Windows Server 2025, the context shows a special Group Policy MSI (Known Issue Rollback) that can be deployed via Group Policy under Computer Configuration → Administrative Templates → the specified policy name. This is the supported way to mitigate certain post-LCU regressions on managed devices.
   • For other 0x800F0922 servicing failures (as in the Windows Server 2019 example), correct the specific underlying condition (for example, enabling the HTTP service in the registry) and then rerun the update so the staged package can complete its transition.
   The context does not document a generic, supported “force finalization” mechanism for staged cumulative updates beyond:
   • Correcting the specific root cause (such as required services or registry state) and reattempting the update, or
   • Installing a newer cumulative update that supersedes the staged one and includes a fix.
   A full OS reinstall or in-place upgrade is not presented as the primary remediation in the official documentation for these issues; instead, Microsoft emphasizes installing the latest cumulative update that contains the fix (for example, KB5079391 for WUSA/network-share issues, KB5077744/KB5078127 for other 25H2 issues) and using KIR where applicable.

For programmatic compliance on Windows 11 25H2 in an enterprise environment, the supported approach based on the context is:

• Track the installed cumulative update level (KB number and package state) and kernel file version rather than relying solely on UBR.
• Ensure devices are updated to the latest cumulative update that includes fixes for known servicing issues (for example, KB5079391 and later for WUSA-related failures).
• Where Microsoft has published Known Issue Rollback policies (for 24H2/25H2 issues), deploy the corresponding Group Policy MSI to managed devices.

References:

• Windows 11, version 25H2 update history
• Resolved issues in Windows 11, version 25H2
• "Failed to be changed to the Absent state. Status: 0x800f0922" when installing updates in Windows Server 2019
• KB5072911: Explorer, the Start menu, and other XAML-dependent apps might not start or close unexpectedly on some enterprise devices
• What's new in Windows 11, version 25H2
• 2025-10 Cumulative Update for Windows 11 Version 23H2 for x64-based Systems (KB5066793) Install error - 0x800f0922 - Microsoft Q&A
• Error 0x800f0922 installing windows update KB5066793 - rollback in phase 31 updating Channel Microsoft-Windows-Store/Operational - Microsoft Q&A
• Mijn windows updates gaan mis - Microsoft Q&A
• Contacting Microsoft Support With an Update Related Question (KB5071959) - Microsoft Q&A
• "Windows Update" Updates failed - Microsoft Q&A