0x80242006 and 0x80240022: update handler and post-reboot install failures

Fix it now

0x80242006 is the update handler refusing a package because the metadata that describes it is invalid. 0x80240022 is not a diagnosis at all: it reports that every update in the operation failed. Microsoft’s mitigation for the first is to discard the local update store so the client fetches fresh metadata and content.

net stop wuauserv
net stop bits
net stop cryptsvc
ren %systemroot%\SoftwareDistribution\DataStore DataStore.bak
ren %systemroot%\SoftwareDistribution\Download Download.bak
ren %systemroot%\System32\catroot2 catroot2.bak
net start cryptsvc
net start bits
net start wuauserv

1. Restart the machine first if Windows is asking for one. For 0x80242014 that is the entire published fix: the post-restart phase is still running and restarting is what finishes it.
2. Scan again from Settings, then Windows Update. The first scan after the rename is slow because the store is being rebuilt from nothing.
3. If 0x80240022 comes back, look at your security software before anything else. Microsoft names antivirus blocking access to folders such as SoftwareDistribution as the most common cause, and says CBS.log identifies which file or folder is being protected.
4. If one named KB still fails, fetch that KB from the Microsoft Update Catalog and install it by hand.

Renaming those three folders discards update history and cached downloads. It uninstalls nothing and it does not touch activation.

If the update installs after that you are done. If it does not, the next section explains which of the five codes you are actually holding.

Why it happens

Windows Update does not install anything itself. It downloads content, then hands each package to a handler, which for a cumulative update means the component-based servicing stack. Between the two there is a contract: the metadata describing the package has to be something the local handler can act on, and the content on disk has to be what that metadata says it is. Four of the five codes here are the handler reporting on that contract; the fifth is a summary that reports on nothing at all.

0x80242006 is WU_E_UH_INVALIDMETADATA. Microsoft’s wording is that a handler operation could not be completed because the update contains invalid metadata, and the mitigation it publishes is to rename the DataStore and Download folders under SoftwareDistribution along with catroot2. That tells you where Microsoft thinks the bad metadata usually lives: in the client’s own cache rather than in the package on the server.

0x80240022 is WU_E_ALL_UPDATES_FAILED, and it is a count rather than a cause. On a machine offered six updates in one pass it says six things went wrong and nothing about any of them. Microsoft’s own note against it is that there are multiple root causes and the most common is security software blocking access to folders such as SoftwareDistribution, with CBS.log naming the protected file. Treat the code as a pointer to the per-update results in update history, never as the answer.

The two post-restart codes describe the other end of the same install. A cumulative update stages its files while Windows is running and completes during a restart with the operating system partly offline. 0x80242014 says that phase is still in progress. 0x80242016 says it finished in a state the agent did not expect. 0x8024200C is the odd one out and the most useful: the handler is telling you it cannot use the delta-compressed content it was given and needs the full self-contained package instead.

Full reference

Reading the five codes as one sequence

Commands that are worth running, and what each proves

Where the evidence lives

• %windir%\Logs\CBS\CBS.log and CBS.persist.log – what the servicing stack did, and the file or folder it could not reach. This is the log Microsoft points at for 0x80240022.
• C:\Windows\Logs\WindowsUpdate – the update client’s own trace files. Get-WindowsUpdateLog converts them into a static readable copy; run it again if you want a fresh one.
• Settings, then Windows Update, then Update history – the per-update result codes hiding behind 0x80240022.
• %windir%\Logs\DISM\dism.log – what a repair attempt did and why it stopped.

The servicing stack question, answered properly

The old advice for a cumulative update that fails on one machine and installs everywhere else was to hunt down the matching servicing stack update and install it first. That has been out of date since February 2021, when Microsoft began shipping the latest servicing stack update inside the cumulative update as a single combined payload for Windows Update, WSUS and the Microsoft Update Catalog, starting with KB4601382 on Windows 10 version 2004 and later.

So the sequencing problem now only shows up on machines that have been offline long enough to be several combined packages behind, or on managed estates that still approve standalone servicing stack updates alongside cumulative ones. If you run WSUS or Configuration Manager, check whether your approval rules still assume the old two-package model; approving both in the same window is what produces the reproducible single-KB failure people still blame on the servicing stack.

Editing pending.xml or deleting servicing entries under Component Based Servicing can leave a machine unable to boot. If you get to the point of considering it, take a full backup or a snapshot first, and treat a reinstall as the cheaper option on a single workstation.

When it is one KB and only one KB

1. Note the KB number from update history and search for it in the Microsoft Update Catalog.
2. Download the package that matches the machine’s architecture and Windows version.
3. Install it directly and watch whether it succeeds. If it does, the fault is in delivery rather than in the package, and the delivery path is what needs attention.
4. If it fails the same way by hand, the fault is on the machine, and the component store repair above is the next step.

Every code this article covers

Confirm the fix worked

1. Update history shows the KB as successfully installed rather than as a failure with a code beside it.
2. Get-HotFix lists the KB number with today’s date.
3. DISM /Online /Get-Packages /Format:Table shows nothing left in Install Pending.
4. A further restart does not return the machine to a configuring screen or re-offer the same update.
5. A second, unrelated update installs normally, which proves you fixed the path rather than one file.

Questions people ask about this