Windows Update error 0x800f0900, explained and fixed

0x800f0900 is CBS_E_XML_PARSER_FAILURE: the Component-Based Servicing engine could not parse an update package’s manifest file (the .mum XML that describes the package), because that file is corrupt. It appears during cumulative update installation, and the corrupt manifest frequently belongs to an earlier update, not the one being installed now.

The fix, in order

  1. Repair the component store. DISM /Online /Cleanup-Image /RestoreHealth, then sfc /scannow, restart, and retry the update. DISM replaces corrupt servicing files, including manifests, when it can source clean copies.
  2. Find the named package in the CBS log. Open C:\Windows\Logs\CBS\CBS.log and search for 0x800f0900 or CBS_E_XML_PARSER_FAILURE. The entries around it name the package whose manifest failed to parse (its KB number). That package is the actual patient.
  3. Reinstall that package from the Update Catalog. Download the named KB’s standalone installer from the Microsoft Update Catalog and run it. A clean copy of the package replaces the corrupt manifest, unblocking later updates.
  4. Run the Windows Update troubleshooter. Settings → System → Troubleshoot → Other troubleshooters → Windows Update → Run. It catches stopped services, cache problems, and registration faults automatically.
  5. Reset the Windows Update components. In an admin Command Prompt, stop the services: net stop wuauserv, net stop cryptSvc, net stop bits, net stop msiserver. Rename C:\Windows\SoftwareDistribution to SoftwareDistribution.old and C:\Windows\System32\catroot2 to catroot2.old, then restart the four services with net start. This rebuilds the download cache and the update database from scratch.

If it still happens

If the corrupt package is a feature-on-demand or language component, DISM with installation media as source (DISM /Online /Cleanup-Image /RestoreHealth /Source:D:\sources\install.wim /LimitAccess) is the stronger repair. If CBS corruption proves widespread, an in-place repair install rebuilds the servicing layer and its manifests in one pass.

Common questions

Why does an old update’s file break a new update? Servicing is cumulative bookkeeping: installing a new package requires reading the manifests of the components it modifies, including ones placed by earlier updates. One unreadable manifest in that chain stops the whole transaction, which is why the named culprit in the log is often not today’s update.

Do I need to read the CBS log myself? Only if DISM does not fix it in one pass. The log step exists because this code has a specific, findable cause, the corrupt package, and the log names it. Copying the lines around the error into a help request also gets you a precise answer from any support forum.

Related errors

Windows Update error 0x800f0988 · Windows Update error 0x80070490 · Windows Update error 0x800f081f