I was getting installation errors on a Windows 2016 server. It started sometime in mid 2025. Every update like "2026-10 Cumulative Update for Windows Server 2016 for x64-based Systems (KB5126868)" was failing. Almost every month.
Finally I got tired of it, and tried to fix this. I did the usual that we were often suggested to do: run
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 Catroot2.old
net start wuauserv
net start cryptSvc
net start bits
net start msiserver
I even got into Safe mode, and tried installing the downloaded .msu file, etc. Nothing worked. Every time when the machine reboots, it would say that it "failed to complete the Windows update, undoing the changes". I started to read the log files in "C:\Windows\Log\CBS", and found nothing that stood out immediately in the CBS.log file.
So I asked Claude Code to go over the files in this folder, immediately it came back with the following:
"I found the cause in the log. KB5126868 doesn't fail on a missing or corrupt file. It fails at the step where it registers event logs, because an event log channel on the server is already owned by a different component.
What happened
At CBS.log:340926 and the lines after it, the update's Events installer step runs during the reboot:
wevtconfig warning #77: Channel Microsoft-Windows-Store/Operational is declared by an existing
provider Microsoft-Windows-Store-Client-UI {53e3d721-2aa0-4743-b2db-299d872b8e3d}.
Error HRESULT_FROM_WIN32(15010) from InstrumentationManifestAssert ...
provider name="Microsoft-Windows-Store" guid="{9c2a37f3-e5fd-5cae-bcd1-43dafeee1ff0}"
channel name="Microsoft-Windows-Store/Operational"
Failed execution of queue item Installer: Events ... A rollback will be initiated
Startup: Failed to process advanced operation queue ... 0x800f0922 - CBS_E_INSTALLERS_FAILED
- The update tries to register the Microsoft-Windows-Store/Operational log channel under the Microsoft-Windows-Store provider (LicenseManager.dll).
- On this server, that channel is already registered to an old provider, Microsoft-Windows-Store-Client-UI ({53e3d721-…}). That registration is probably left over from something earlier.
- Event log configuration refuses the duplicate and returns error 15010, a configuration error. Windows then rolls the whole update back, so you see 0x800f0922 and a revert at reboot.
- The same Events failure appears in CbsPersist_20261018073732.log and CbsPersist_20261018084813.log, so it's the same problem on every attempt."
"Fix
Remove the stale channel registration so the update can register it fresh. Run this in an elevated PowerShell on the server, and back the keys up first:
$base = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT'
New-Item C:\Temp\WinevtBackup -ItemType Directory -Force | Out-Null
# Back up the conflicting channel and the old publisher
reg export "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-Store/Operational" C:\Temp\WinevtBackup\Channel-Store-Operational.reg /y
reg export "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\{53e3d721-2aa0-4743-b2db-299d872b8e3d}" C:\Temp\WinevtBackup\Publisher-StoreClientUI.reg /y
# Check who owns the channel now (should show 53e3d721...)
Get-ItemProperty "$base\Channels\Microsoft-Windows-Store/Operational"
# Remove the stale channel registration
Remove-Item "$base\Channels\Microsoft-Windows-Store/Operational" -Recurse
Remove-Item "$base\Publishers\{53e3d721-2aa0-4743-b2db-299d872b8e3d}" -Recurse
AI to the rescue, again. The fix worked. If I had to read through all the logs myself, it would have taken 100 times longer, all for a problem that is not really worth the time.
Human programmers at Microsoft failed to log a fatal error as what it is. It ended up costing people tons of time to figure out that it is causing complete failures in the installation. I suppose that with human programmers, Microsoft just cannot afford to log things properly. So, until AI takes over, Microsoft's update log will just remain crappy like this.
