Direct answer: When a cumulative update fails with 0x800f0831 (CBS_E_STORE_CORRUPTION) or 0x80073712 (component store inconsistent), Microsoft ties the error to the Windows component store, the set of packages and manifests servicing builds on. Other codes, such as 0x8024002E (update service disabled), point elsewhere, so read the code and CBS.log before anything else. Then run DISM's CheckHealth and ScanHealth and sfc /verifyonly: these scan without repairing, though they write to their logs. Only after that decide on a repair, using Windows Update or a repair source of the same OS version, language components and patch level. Never delete WinSxS content or force the update past its checks.
Why it matters
A server that cannot take its monthly cumulative update stays exposed to every security fix in it, later updates build on the same store, and each failed attempt costs a maintenance window. Servers patched only from WSUS or Configuration Manager are exposed to the 0x800F0831 case, which Microsoft says is more likely without access to Microsoft Update.
How it works
The component store and the servicing stack
Microsoft describes the servicing stack as "the component that installs Windows updates". It contains component-based servicing (CBS), which also underlies DISM, System File Checker, changing Windows features or roles, and component repair. An update is applied as packages whose manifests are recorded in the store. Microsoft's Windows Update repair article lists what DISM checks: files under %SYSTEMROOT%\Servicing\Packages and %SYSTEMROOT%\WinSxS\Manifests, and the registry under HKLM\Components, HKLM\Schema and HKLM\Software\Microsoft\Windows\CurrentVersion\Component Based Servicing. When DISM detects incorrect manifests, cabinets or registry data, "it may replace the incorrect data with a corrected version".
Where the Windows Update log comes from
Microsoft states that Windows Update "no longer directly produces a WindowsUpdate.log file. Instead, it produces .etl files". Get-WindowsUpdateLog merges and converts them into a static copy that "does not update ... unless you run Get-WindowsUpdateLog again." For Windows 10 versions before 1709 (build 16299), decoding "requires access to a Microsoft symbol server". The log files page is scoped to Windows 10 and 11; its applicability to each Server build is not stated.
Why one damaged package blocks the next update
For error 0x800F0831, Microsoft gives the cause directly: "the update that can't be installed requires the manifest of a previous update package." CBS.log then shows lines such as Store corruption, manifest missing for package: <Missing_Package> with CBS_E_STORE_CORRUPTION.
The error codes point at the layer
Microsoft's KB 947821 table maps error codes. Some of them:
| Code | Name | Meaning (Microsoft) |
|---|---|---|
| 0x800f0831 | CBS_E_STORE_CORRUPTION | CBS store is corrupted |
| 0x80073712 | ERROR_SXS_COMPONENT_STORE_CORRUPT | The component store is in an inconsistent state |
| 0x800736CC | ERROR_SXS_FILE_HASH_MISMATCH | A component's file does not match its manifest |
| 0x800F081F | CBS_E_SOURCE_MISSING | The source for the package or file not found |
| 0x800f0906 | CBS_E_DOWNLOAD_FAILURE | Content download failure for Feature on Demand or corruption repair |
| 0x8024002E | WU_E_WU_DISABLED | Windows Update Client service is disabled |
The last code is not store corruption, which is why reading the code comes before any repair.
Where repairs come from
DISM needs known good copies of the damaged files. Microsoft states that Windows Update is the default repair source, "if it's allowed by the policy settings on the computer", and that Group Policy can name other locations under Computer Configuration, Administrative Templates, System, "Specify settings for optional component installation and component repair". With /Source, DISM can use a mounted image, a shared Windows folder of a working installation, a side-by-side folder or a WIM file. /LimitAccess stops DISM using Windows Update.
The source matters, and Microsoft's requirements belong together:
- Same OS version. The KB 947821 example says a repair source computer "must be running the same operating system version."
- Patch level. "Make sure the source is patched to the latest Cumulative Update. If the target OS is patched to a higher level than the source, adding features or repairing Operating Systems may fail because the target OS needs updated files that are not present in the source." This is about the same OS version patched far enough, not a later Windows version.
- Media. "Only use RTM media regardless of whether the source is a WIM or a mounted Windows image. Refresh media has older file versions excluded from the media and the target operating system may need these files."
- Languages. "You must include all of the relevant language packs with your repair source files for the locales your image supports."
With more than one /Source, files are taken from the first location where they are found.
Background with a client scope: servicing stack and checkpoint updates
Microsoft's servicing stack page (which lists Windows 11, Windows 10 and Windows Server) states that the combined cumulative update carrying the servicing stack "is available on Windows 10, version 2004 and later starting with KB4601382". The DISM page describes "checkpoint" cumulative updates "Starting with Windows 11, version 24H2". Neither page names a Windows Server version for these boundaries, so this article does not use them as a Server cause. For a Server build, follow the prerequisites stated in that month's update release notes.
SFC is a different check
sfc "scans and verifies the integrity of all protected system files and replaces incorrect versions with correct versions". It checks the files Windows runs from, not the store's package records. Microsoft's repair article describes sfc /scannow as a quick check, and DISM /Cleanup-Image as "a more extensive check that can repair issues with the store". Both of Microsoft's update-failure procedures run DISM first and SFC after. The 0x800F0831 procedure then says "Restart the device"; KB 947821 moves from SFC to retrying the update without a separate restart step.
Diagnostics that do not repair
None of these were run for this article. They need an elevated prompt. DISM and SFC scans write to their own logs (CBS.log, DISM.log) and take time and disk I/O; they are not repairs, but they are not zero-impact. Run them in a quiet period.
- The error code. Record it from Windows Update history and the Setup event log, which KB 947821 names as the place to check.
- CBS.log. Read
%windir%\Logs\CBS\CBS.logaround the failed attempt for lines such asmanifest missing for packageand note the package name. - Windows Update log (creates a file).
Get-WindowsUpdateLogwrites a converted, static copy. Generate it after the failure, note the time it was generated, and read the window around the failed attempt. For 0x800F0831, Microsoft's article showsFATAL: CBS called Error with 0x800F0831in this log. - Flag check:
DISM /Online /Cleanup-Image /CheckHealthMicrosoft: checks "whether the image has been flagged as corrupted by a failed process and whether the corruption can be repaired". DISM reports the image as healthy, repairable or non-repairable. - Full scan:
DISM /Online /Cleanup-Image /ScanHealth"Scans the image for component store corruption. This operation will take several minutes." - System files:
sfc /verifyonlyscans protected system files "without performing repairs". - Repair source in effect. Read the "Specify settings for optional component installation and component repair" policy in the resultant Group Policy, and whether the server can reach Windows Update or only WSUS.
- Version and language. Record the OS build, update revision and installed language packs, so any repair source can be matched.
Candidate causes (hypotheses to test)
| Candidate | Evidence | Next decision |
|---|---|---|
| Manifest of an earlier package missing | 0x800f0831; manifest missing for package in CBS.log |
DISM repair or the missing package (KB 4477073) |
| Corrupt payload or manifest | ScanHealth reports corruption | DISM repair from a matching source |
| Repair source missing or mismatched | 0x800f081f after a repair attempt | Source of same version, language and patch level |
| Windows Update blocked and no source named | 0x800f0906 or 0x800f081f | Repair source policy or /Source |
| Windows Update service disabled | 0x8024002E | Service configuration, not the store |
Decision guidance
Every item below is a change. Each needs a change record, a current backup and a maintenance window. None were executed for this article.
| Decision | Prerequisites | Reference |
|---|---|---|
Repair the store with DISM /Online /Cleanup-Image /RestoreHealth |
CheckHealth or ScanHealth reports repairable; repair source confirmed (Windows Update reachable, or /Source matching version, language, patch level and RTM media, with /LimitAccess) |
KB 947821; Repair a Windows Image; Configure a Windows Repair Source |
Repair protected system files with sfc /scannow |
DISM repair completed with "The restore operation completed successfully" | KB 947821; sfc |
| Restart before retrying | Author's operational recommendation; the 0x800F0831 procedure includes it, KB 947821 does not | KB 4477073 |
| Retry the cumulative update | Repairs complete; scans clean | Update release notes |
| Install the missing package for 0x800f0831 | DISM cannot supply it; package ID from CBS.log; update for this OS from the Microsoft Update Catalog | KB 4477073 Method 2 |
| KB 947821 advanced procedure (extracting update files to a source folder) | Support-level task; script not reviewed for this article | KB 947821; Microsoft support |
| Rebuild or restore | DISM reports non-repairable | Separate change; backup and restore plan |
If RestoreHealth does not report success, read CBS.log before any further step.
What not to do
- Do not delete files from WinSxS or the folder itself. Microsoft warns this "may severely damage your system so that your PC might not boot and make it impossible to update."
- Do not run
/StartComponentCleanup /ResetBaseas a repair step. Microsoft states installed updates cannot be uninstalled afterwards. - Do not use
/Add-Package /IgnoreCheckto push the update past its applicability checks. - Do not use a source of another OS version, missing language components, or refresh media.
- Do not use
/RevertPendingActionson a running server. Microsoft states it is not supported on a running operating system. - Do not disable component cleanup to save time. Microsoft strongly recommends against it.
Limitations
- Untested: no command was run in a lab, so runtime side effects of the scans are not measured.
- The KB 947821 advanced procedure script was not reviewed.
- Windows Server 2012 R2 and earlier are not covered.
- Server-specific boundaries for combined servicing stack and checkpoint updates were not found in the fetched sources.
- The Windows Update log files page is scoped to Windows 10 and 11.
- Third-party patch tools, WSUS approval problems, download failures and in-place upgrade repair are not covered.
Acceptance checklist
- [ ] The error code, CBS.log lines and log generation time are recorded before any repair.
- [ ] Any repair source used matches OS version, language components and patch level, from RTM media.
- [ ] CheckHealth and ScanHealth report no corruption after any repair.
- [ ] The cumulative update shows as installed after the server's restart.
- [ ] The next cumulative update is tracked as its own check, with its result recorded.
Sources
Displayed dates as shown when accessed on 30 October 2026.
- Microsoft Learn, Fix Windows Update corruptions and installation failures. 2026-02-12.
- Microsoft Learn, Error 0x800F0831 when you install an update. 2026-02-12.
- Microsoft Learn, DISM Operating System Package (.cab or .msu) Servicing Command-Line Options. 2024-09-10.
- Microsoft Learn, Repair a Windows Image. 2021-12-15.
- Microsoft Learn, Configure a Windows Repair Source. 2021-12-15.
- Microsoft Learn, sfc. 2024-11-01.
- Microsoft Learn, Servicing stack updates. 2026-02-11.
- Microsoft Learn, Clean Up the WinSxS Folder. 2025-03-10.
- Microsoft Learn, Windows Update log files. 2026-02-11.
- Microsoft Learn, Get-WindowsUpdateLog. Not displayed in retrieved copy.
Related articles
- VSS writer failed: diagnose Windows shadow copy errors before the next backup
- Windows server runs out of memory without a busy process: measure first, then check pool and handle growth
- Print Spooler crashes on Remote Desktop hosts: suspected driver faults, isolation and Point and Print
Learning notes
- The error code decides whether the store, the repair source or the update service is the suspect.
- CheckHealth, ScanHealth and
sfc /verifyonlyscan without repairing; they still write logs. - A repair source matches OS version, languages and patch level, from RTM media.
- DISM repair comes before SFC; a restart before the retry is a recommendation.
- Servicing stack and checkpoint boundaries in the fetched pages are client-scoped.