0x800F0922: cumulative update fails when the system partition is full

Fix it now

0x800F0922 is CBS_E_INSTALLERS_FAILED: an advanced installer inside the update package failed, and the code itself says nothing about why. The servicing log names which one, so read that before you change anything on disk.

DISM.exe /Online /Cleanup-image /Restorehealth
sfc /scannow
Dism /english /online /get-packages /format:table | findstr /i "Staged"

1. Open %SystemRoot%\Logs\CBS\CBS.log and search back for the first failure rather than the last. CBS.persist.log holds the older entries once the current log has rolled.
2. Search that log for ERROR_FILE_NOT_FOUND and for SecureBootEncodeUEFI, which is the failing task Microsoft documents most often behind this code.
3. Check the Task Scheduler Operational log for Event ID 146, which is what that broken task writes.
4. Count the files in C:\Windows\Temp. Microsoft documents this code appearing once that folder passes roughly 65,000 files, and the fix is simply to empty it.
5. If the get-packages output lists staged packages from earlier failed attempts, remove them as shown in the reference section, then retry the update.

Restart before retrying. Servicing will not begin a new transaction while an earlier one is still pending, and a retry in that state fails without telling you why.

If the update installs and survives the restart, you are done. If it fails again, the next section covers each cause Microsoft documents for this code and how to tell them apart.

Why it happens

A cumulative update is not only files. Alongside the components it replaces, it carries advanced installers and generic commands: small pieces of work that run during servicing to reconfigure something the new files depend on. 0x800F0922 is the servicing stack reporting that one of those failed. That is all it says. It does not name the installer, and it says nothing about your disk, your network or your machine’s capacity.

This matters because the code has attracted a large body of advice that treats it as a disk space error. Microsoft has three separate pages covering it and not one attributes it to a full system partition or to a VPN. What they do attribute it to is a corrupted scheduled task, a permissions problem on the folder holding licence tokens, and a Windows Temp directory with more files in it than servicing can work through. Those are the causes to work, and the servicing log tells you which.

The three codes that travel with this one are the genuine capacity codes, which gives you a clean test. 0x8007000E means not enough storage is available, 0x80070027 means the disk is full, and 0x80070718 means a quota has been exhausted. If any appear alongside, capacity really is the problem. If 0x800F0922 appears on its own, it is an installer failure and freeing space will not touch it.

Full reference

Why the code is so quiet about its cause

CBS_E_INSTALLERS_FAILED is raised at the layer that runs advanced installers, not inside the installer that failed. By the time the error surfaces, the specific failure has already been written to the log and the stack is reporting only that the batch did not succeed. This is also why the same code appears when installing an update, when uninstalling a server role and when enabling a feature: all three run advanced installers, and any of them can fail for a reason particular to itself. Reading the log is not a more diligent version of guessing; it is the only way to tell these cases apart.

Clearing packages left staged by failed attempts

Dism /english /online /get-packages /format:table | findstr /i "Staged"

Dism /online /remove-package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~14393XXXX

Substitute the exact package name from the first command’s output. The example above shows the shape of the name, not a name to type.

Repairing the SecureBootEncodeUEFI task

The task is identified by a GUID held in the registry. Read the GUID first, then remove the four entries that describe the task so that Windows can recreate it.

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

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

Back up the TaskCache key before deleting anything under it, and substitute the GUID the first command returns. Deleting entries for a different task removes that task.

About the reserved partition

A great deal of advice for this code sends you into the EFI system or System Reserved partition to delete language font files after assigning it a drive letter. That procedure appears nowhere in Microsoft’s documentation, it is offered as the fix for a cause Microsoft does not attribute to this code, and it operates on the partition that makes the machine bootable. It is not in this article for those reasons.

A reserved partition genuinely too small to service is a real condition, and Windows has its own distinct message for it when it happens during an upgrade. If that is what you are seeing, you are looking at a different problem from this code, and the honest answer is that extending that partition means moving the partition next to it, which the built-in tooling will not do. On a managed fleet the practical route is redeployment with a current image, which produces a correctly sized layout. On a single machine, image it before anyone attempts partition surgery.

Logs, and what to search them for

If none of the documented causes apply

• Repair the component store first with RestoreHealth and then the file checker, in that order, because a damaged store produces servicing failures of its own that look like this one.
• Check whether the same update fails on more than one machine. A single machine points at local state; a fleet points at the package or at a policy applied to all of them.
• Try the update as a standalone package from the Microsoft Update Catalog, which changes how it is delivered and sometimes produces a more specific error.
• Keep the CBS.log excerpt around the first failure. It is the one thing that turns this from a generic code into a specific defect anyone can act on.

Every code this article covers

Confirm the fix worked

1. Retry the update and confirm it installs and survives the restart.
2. Check Windows Update history and confirm the entry shows as successfully installed rather than retried.
3. Search CBS.log after the successful run and confirm no new advanced installer failures were written.
4. If you removed staged packages, confirm get-packages no longer lists anything in the Staged state.
5. Confirm the following month’s update installs without intervention.

Questions people ask about this