Registry Fix for Error 0x800f0922 and Update Rollback Issues
Summary: If your Windows Server 2016 cumulative updates are failing to install—reaching 100% then rolling back with error 0x800f0922—this article explains the multiple causes and fixes. The issues are particularly common on servers that were upgraded from Windows Server 2012 R2, and on Remote Desktop Services (RDS) Session Host servers.
The Problem
Since late 2025, many Windows Server 2016 administrators have been experiencing a frustrating issue: cumulative security updates appear to install successfully, reaching 100%, but then roll back during the restart with the message:
“We couldn’t complete the updates. Undoing changes.”
The error code associated with this failure is typically 0x800f0922 (CBS_E_INSTALLERS_FAILED). This has affected multiple cumulative updates including KB5066836, KB5066136, KB5070882, KB5071543, KB5073722, and others.
Who’s Affected?
This issue primarily affects:
- Windows Server 2016 systems upgraded from Windows Server 2012 R2 — rather than clean installations
- Remote Desktop Services (RDS) Session Host servers — particularly those with active user profiles
- Servers with MSMQ (Message Queuing) installed — especially with the December 2025 update (KB5071543)
If you have multiple Server 2016 machines and only some are experiencing this issue, check whether the affected servers fall into one of these categories.
Issue 1: Event Log Provider Registry Conflict
The Cause
The update fails because of a conflict between two Windows Event Log providers trying to claim ownership of the same channel (Microsoft-Windows-Store/Operational).
When cumulative updates install, they include an event log manifest that tries to register a provider called Microsoft-Windows-Store for this channel. However, an orphaned registry key from a previous Windows Store component has already claimed ownership under a different provider name (Microsoft-Windows-Store-Client-UI).
The Windows Event Log system doesn’t allow two providers to own the same channel. When the update installer attempts to register its manifest, it fails with error 15010 (ERROR_EVT_INVALID_PUBLISHER_NAME). This error triggers a rollback of the entire cumulative update.
The orphaned registry key is typically left behind from a previous Windows Store component that was removed or updated incorrectly—common on Server 2016 where the Store isn’t really used but remnants still exist.
If you check the CBS.log file (located in C:\Windows\Logs\CBS), you’ll see an error message like:
Channel Microsoft-Windows-Store/Operational is declared by an existing provider Microsoft-Windows-Store-Client-UI{{53e3d721-2aa0-4743-b2db-299d872b8e3d}}
Or:
Error HRESULT_FROM_WIN32(15010) from InstrumentationManifestAssert
The CBS.log may reference one of these GUIDs:
- {53e3d721-2aa0-4743-b2db-299d872b8e3d} — Microsoft-Windows-Store-Client-UI
- {9c2a37f3-e5fd-5cae-bcd1-43dafeee1ff0} — Microsoft-Windows-Store
Why Standard Repair Tools Don’t Help
You may also see errors in CBS.log referencing a corrupted manifest file:
Failed to load xml document C:\WINDOWS\System32\LicenseManager-Events.man. Incorrect function.
This can lead you to believe the manifest file itself is corrupted and needs repair. However, this is a symptom, not the cause. The manifest file fails to load because the registry conflict prevents it from being processed correctly.
Running DISM /Online /Cleanup-Image /RestoreHealth or sfc /scannow will not fix this issue because:
- The component store isn’t actually corrupted
- The manifest file itself is valid
- The problem is in the Event Log registry, which these tools don’t repair
Similarly, scripts that attempt to re-register event manifests by searching for .manifest files won’t help—those are SxS assembly manifests, not event log manifests (.man files). The wevtutil command expects .man files.
The Fix
Step 1: Check if the Registry Key Exists
First, verify whether the problematic registry key is present:
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\{53e3d721-2aa0-4743-b2db-299d872b8e3d}"
If you see output showing Microsoft-Windows-Store-Client-UI, this fix applies to your situation. If the key doesn’t exist, skip to the other issues below.
Step 2: Back Up and Delete the Registry Key
Using Command Prompt (Run as Administrator):
reg export "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\{53e3d721-2aa0-4743-b2db-299d872b8e3d}" C:\Temp\StoreClientUI_backup.reg /y
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\{53e3d721-2aa0-4743-b2db-299d872b8e3d}" /f
Step 3: If It Still Fails
You may also need to delete a related Channels registry key:
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-Store/Operational" /f
Step 4: Reboot and Retry the Update
Automated Fix for Multiple Servers (RMM Deployment)
If you need to deploy this fix across multiple servers via RMM, use this batch script:
@echo off
if not exist "C:\Temp" mkdir "C:\Temp"
reg export "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\{53e3d721-2aa0-4743-b2db-299d872b8e3d}" "C:\Temp\StoreClientUI_backup.reg" /y
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\{53e3d721-2aa0-4743-b2db-299d872b8e3d}" /f
The /y on the export overwrites if the backup already exists, making it safe to run multiple times.
Issue 2: RDS User Profiles Preventing Update Completion
The Cause
On Remote Desktop Services Session Host servers, the update can fail during the commit phase because user profile registry hives (NTUSER.DAT files) cannot be unloaded. This happens when:
- Users are still logged in during the update
- Orphaned user sessions exist
- Profile registry hives remain loaded after users disconnect
In the CBS.log, you’ll see entries like:
Failed unloading hive file: \??\C:\Users\username\NTUSER.DAT
Multiple user profiles failing to unload will cause the update to roll back.
The Fix
Step 1: Log Off All Users
Check for active sessions:
query user
Log off each session:
logoff <session_id>
Step 2: Prevent New Logins
chglogon /disable
Step 3: Force Unload Orphaned Profile Hives
If any profiles remain loaded, manually unload them (replace the SID with the actual values from your CBS.log):
reg unload "HKU\S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx"
Step 4: Reboot the Server
Reboot to ensure all profiles are completely unloaded.
Step 5: Install the Update Immediately
Install the update before any users log in:
wuauclt /detectnow /updatenow
Or install manually:
wusa.exe C:\path\to\update.msu /quiet /norestart
Step 6: Re-enable Logins After Update
chglogon /enable
Issue 3: MSMQ (Message Queuing) Conflict
The Cause
The December 2025 update (KB5071543) introduced changes to the MSMQ security model and NTFS permissions on C:\Windows\System32\MSMQ\storage. This causes MSMQ-dependent applications and IIS sites to fail with errors like:
- “Insufficient resources to perform operation”
- “The message file cannot be created”
If MSMQ is installed, the update may also fail to install or roll back.
The Fix
Option A: Install the Out-of-Band Fix
Microsoft released KB5074974 (December 18, 2025) to fix the MSMQ issue. Download it from the Microsoft Update Catalog and install after KB5071543:
wusa.exe KB5071543.msu /quiet /norestart
wusa.exe KB5074974.msu /quiet /norestart
shutdown /r /t 60
Option B: Temporarily Disable MSMQ
If the out-of-band fix also fails:
- Disable MSMQ before updating:
dism /online /disable-feature /featurename:MSMQ-Server /norestart - Install the update and reboot
- Re-enable MSMQ:
dism /online /enable-feature /featurename:MSMQ-Server /all /norestart - Reboot again
Issue 4: Network Drivers Installation Failure
The Cause
Some updates fail during the “Network Drivers” phase of installation, typically due to services consuming resources or conflicting with the update process. In CBS.log, you’ll see:
Failed execution of queue item Installer: Network Drivers ({a111f280-5923-47c0-9a68-d0bafb577901}) with HRESULT 800106d9
The Fix
Perform a Clean Boot Before Installing Updates:
- Run msconfig
- Go to Services tab
- Check Hide all Microsoft services
- Click Disable all
- Go to Startup tab > Open Task Manager > Disable all startup items
- Reboot and install updates
Or Disable Specific Services:
sc config W3SVC start= disabled
sc config WAS start= disabled
net stop W3SVC
net stop WAS
Install the update, reboot, then re-enable:
sc config W3SVC start= auto
sc config WAS start= auto
Issue 5: .NET Framework Version
The Cause
Current security patches are built for .NET Framework 4.8. Servers running older versions (like 4.6.2, the Server 2016 default) may experience update failures or rollbacks.
The Fix
Check your .NET Framework version:
reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" /v Release
If not running 4.8, download and install it from: https://dotnet.microsoft.com/download/dotnet-framework/net48
Diagnostic Steps
Check the CBS.log
The CBS.log file contains detailed information about why updates failed:
notepad C:\Windows\Logs\CBS\CBS.log
Search for:
- error
- fail
- rollback
- 0x800f0922
- HRESULT_FROM_WIN32(15010)
- Microsoft-Windows-Store-Client-UI
- Network Drivers
- Failed unloading hive file
Verify Current Build
winver
Or:
systeminfo | findstr "OS Version"
Check Installed Updates
wmic qfe list brief /format:table
Monitoring Script for RMM
Use this script to identify which servers need the registry fix and which are behind on updates:
@echo off
setlocal
for /f "tokens=2 delims==" %%a in ('wmic os get Version /value ^| find "="') do set VERSION=%%a
set KB5073722=Not Installed
wmic qfe get HotFixID | find "KB5073722" >nul && set KB5073722=Installed
set REGKEY=Not Present
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\{53e3d721-2aa0-4743-b2db-299d872b8e3d}" >nul 2>&1 && set REGKEY=Present
echo %COMPUTERNAME%,%VERSION%,%KB5073722%,%REGKEY%
This outputs CSV format for easy reporting: SERVERNAME,10.0.14393,Not Installed,Present
Servers showing Not Installed,Present need the registry fix before the update will succeed.
General Patch Compliance Script
To monitor whether any Windows device is falling behind on updates:
@echo off
setlocal EnableDelayedExpansion
:: Get OS info
for /f "tokens=2 delims==" %%a in ('wmic os get Caption /value ^| find "="') do set OS=%%a
for /f "tokens=2 delims==" %%a in ('wmic os get Version /value ^| find "="') do set VERSION=%%a
:: Get most recent patch date
set LASTPATCH=Unknown
for /f "skip=1" %%a in ('wmic qfe get InstalledOn ^| sort') do (
if not "%%a"=="" set LASTPATCH=%%a
)
:: Calculate days since last patch
for /f %%a in ('powershell -command "(New-TimeSpan -Start (Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 1).InstalledOn -End (Get-Date)).Days"') do set DAYS=%%a
echo Computer: %COMPUTERNAME%
echo OS: %OS%
echo Version: %VERSION%
echo Last Patch: %LASTPATCH%
echo Days Since Patch: %DAYS%
:: Alert thresholds (adjust as needed)
if %DAYS% GTR 60 (
echo Status: CRITICAL - Over 60 days behind
exit /b 2
) else if %DAYS% GTR 35 (
echo Status: WARNING - Over 35 days behind
exit /b 1
) else (
echo Status: OK
exit /b 0
)
Exit codes for RMM alerting:
- 0 = OK (patched within 35 days)
- 1 = Warning (35-60 days)
- 2 = Critical (60+ days)
Applying Fixes to Multiple Servers
If you have multiple Windows Server 2016 machines experiencing this issue:
- Check the CBS.log on each affected server to identify which specific issue applies
- Compare working servers vs. failing servers to identify common factors:
- Were they upgraded from 2012 R2?
- Do they run RDS Session Host?
- Is MSMQ installed?
- Apply the appropriate fix based on the CBS.log errors
- Use the RMM scripts above to deploy fixes at scale
When All Else Fails
If none of the above fixes work:
- Open a Microsoft Support case — these are known issues affecting many administrators
- Wait for the next cumulative update — Microsoft often fixes installer issues in subsequent releases
- Disable Windows Update prompts to stop nagging users while you investigate:
sc config wuauserv start= disabled net stop wuauserv reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v NoAutoUpdate /t REG_DWORD /d 1 /f
When the Root Cause Cannot Be Identified
In some cases, the CBS.log will show errors (such as HRESULT_FROM_WIN32(15010) or Event provider conflicts) but the corresponding registry keys do not exist on the server. This can happen when:
- The conflict is occurring at a different level than the registry
- Multiple issues are compounding each other (e.g., Event provider errors combined with RDS profile issues)
- The error is a symptom of a deeper component store problem that standard repair tools (DISM, SFC) don’t detect
If you’ve tried all the fixes and the update still fails:
- Compare working vs. non-working servers in detail (installed roles, software, original install date, base image)
- Consider that some servers may require a clean installation rather than continued troubleshooting (the last resort for us)
- Document your findings for Microsoft Support — they may have access to diagnostic tools not publicly available
- The next cumulative update may resolve the issue as Microsoft continues to address these problems
Reality check: Sometimes Windows Update issues on older servers cannot be fully diagnosed or resolved. If the servers are functioning correctly otherwise, disabling update prompts and waiting for either a future fix or planned server replacement may be the pragmatic approach.
Looking Ahead
These issues highlight challenges with:
- In-place upgrades leaving legacy registry entries
- RDS environments having unique update requirements
- Complex interactions between Windows features during updates
Server 2016 support ends in January 2027. Consider planning migrations to newer Windows Server versions where feasible.
Need help with Windows Server updates? Get in touch—we’re happy to help.
Give our friendly experts a call on 020 3327 0310.
Last updated: March 2026