Back to Blog

0x800F0922 CBS_E_INSTALLERS_FAILED When Installing Windows Updates

Christopher 4 min read
referencewindows

0x800F0922 is the Component-Based Servicing error CBS_E_INSTALLERS_FAILED. It appears when a Windows update fails to install, in the Windows Update history and in event 20 from Microsoft-Windows-WindowsUpdateClient in the System log. The event message reads "Installation Failure: Windows failed to install the following update with error" followed by the code and the update's name with its KB number. The same code appears when removing a Windows Server role or feature with Server Manager or Uninstall-WindowsFeature, with the message "CBS_E_INSTALLERS_FAILED Processing advanced installers and generic commands failed".

What it means

An update package runs advanced installers for some of its components, such as registering a scheduled task. One of those installers failed, so Windows rolls the update back after all the operations in the installer queue finish. In Microsoft's example the failure is logged at startup and the update is then rolled back.

How to find the cause

Confirm which update failed and when, from an elevated PowerShell prompt.

Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'Microsoft-Windows-WindowsUpdateClient'
    Id           = 20
} -MaxEvents 10 | Select-Object TimeCreated, Message | Format-List

Find the installer that failed in CBS.log, at C:\Windows\Logs\CBS\CBS.log. Older entries roll over into CBSpersist files in the same folder.

Select-String -Path C:\Windows\Logs\CBS\CBS.log -Pattern 'Failed execution of queue item Installer' -SimpleMatch | Select-Object -First 5

The line reads "Failed execution of queue item Installer" followed by the installer's name and the HRESULT it returned. A few lines later CBS logs "Failed to process advanced operation queue" with "HRESULT = 0x800f0922 - CBS_E_INSTALLERS_FAILED", then the rollback. Above the failure, a "Begin executing advanced installer phase" block lists the component being installed and the installer name.

Run the same search on three or four affected machines. The same installer name and the same component on every machine points at something those machines share.

Fixes

When the installer is Task Scheduler and the component is Microsoft-OneCore-SecureBootEncodeUEFI-Task, the SecureBootEncodeUEFI scheduled task is corrupted. Microsoft's article on this case also shows event 146 in the Microsoft-Windows-TaskScheduler/Operational log, "Task Scheduler failed to load task \Microsoft\Windows\PI\SecureBootEncodeUEFI at service startup". Find and remove the staged update packages first.

Dism /english /online /get-packages /format:table | findstr /i "Staged"
Dism /online /remove-package /PackageName:<staged package name>

Then get the task's GUID.

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\Microsoft\Windows\PI\SecureBootEncodeUEFI" /v ID

Delete the task's registry entries with that GUID, then install the update again.

reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Maintenance\{GUID}" /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Plain\{GUID}" /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks\{GUID}" /f
reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree\Microsoft\Windows\PI\SecureBootEncodeUEFI" /f

When the installer is a different one, check what changed for that component on the affected machines, such as a service that was disabled or a scheduled task that was removed, and restore it before installing the update again.

When the HRESULT after the installer name is one of the component store errors in Microsoft's article Fix Windows Update corruptions and installation failures, repair the component store and the system files, then retry the update.

DISM.exe /Online /Cleanup-Image /RestoreHealth
sfc /scannow

When 0x800F0922 appears while removing a Windows Server role or feature, check how many files C:\Windows\Temp holds. More than 65,000 files there can cause it. Delete the contents of C:\Windows\Temp, then remove the role or feature again.

Related events and errors

Where ET Ducky shows it

I build ET Ducky, and its patch management talks to the Windows Update Agent directly and installs updates by KB number. You'd tag a few machines as your first ring and schedule updates to that tag before the rest. A patch is marked successful only when the kernel events show services back up with no crash loops. The deployment moves to the next ring only after the machines in the current ring pass that check, and a regression in a ring pauses the deployment. You can also open a Live Session shell from the browser without the need for a VPN and run the CBS.log search above on each machine in the ring.

Sources

Patch rings that check the machine after the reboot

Read how ET Ducky rolls Windows and Linux updates out in rings, checks each machine after the install, and pauses the deployment when a ring regresses.

Read the patch management docs