Windows error 0x80073712? Repair the store before the files

1. What the component store is, and why this stops updates

Microsoft lists 0x80073712 in its table of common corruption errors as ERROR_SXS_COMPONENT_STORE_CORRUPT, described as the component store being in an inconsistent state. It sits alongside a family of related codes with the same character — 0x800F0831 for a corrupted CBS store, 0x8007000D for invalid data, 0x80070490 for a not-found error during update search, 0x800736CC where a component’s file does not match the verification information in its manifest.

The store is not an abstraction. Microsoft documents exactly what DISM checks for integrity: files under %SYSTEMROOT%\Servicing\Packages and %SYSTEMROOT%\WinSxS\Manifests, and registry data under HKEY_LOCAL_MACHINE\Components, HKEY_LOCAL_MACHINE\Schema and HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Component Based Servicing. When DISM detects incorrect manifests, cabinets or registry data, it can replace the incorrect data with a corrected version.

That is why retrying the update is pointless. Windows Update is being handed an inconsistent store to install into, and it will report the same code every time until something repairs the store itself.

If several different updates are failing rather than one, store corruption is a much stronger hypothesis than a problem with any individual update.

2. The repair, in Microsoft’s order

Open an elevated Command Prompt — Start, type Command Prompt, right-click it and choose Run as administrator. Then run DISM.exe /Online /Cleanup-image /Restorehealth and let it finish. Microsoft warns that it may take several minutes, and it is normal for the progress indicator to sit at the same percentage for a long stretch. Do not close the window because it looks stuck.

When DISM has completed, run sfc /scannow in the same window, and again allow several minutes. Then close the command prompt and run Windows Update again.

The order is the part that gets reversed most often. SFC repairs protected system files by replacing them with known-good copies drawn from the component store. If the store is the thing that is corrupt, SFC has nothing trustworthy to copy from — so running SFC first can report failures that DISM would have fixed, or repair a file from a bad source. DISM repairs the store; SFC then repairs the files using it.

Microsoft’s success criterion is explicit: if the scan result reads “The restore operation completed successfully”, move on to the next step. If it does not, the answer is in CBS.log rather than in another attempt.

3. When DISM cannot reach a source

Microsoft is clear that DISM repair works best when connected to Microsoft Update servers, because that is where it fetches missing or corrupted files from. A machine that is offline, behind a restrictive proxy, or pointed at WSUS rather than Windows Update may find nothing to repair with — and a DISM run that cannot obtain replacements typically ends with 0x800F081F, source missing.

The documented alternative is to use a working Windows installation as the repair source: DISM.exe /Online /Cleanup-Image /RestoreHealth /Source: followed by a UNC path to that machine’s Windows folder, with /LimitAccess. Microsoft’s one condition is that the repair source computer must be running the same operating system version, which in practice means the same build, not merely the same name.

Files from a mounted ISO, a network share or a USB or DVD work the same way. What matters is that the source matches the installed version. A source from a different build will not satisfy the repair and will send you round the same loop.

4. Reading CBS.log when the repair does not stick

DISM writes a log capturing every issue it found or fixed, at %windir%\Logs\CBS\CBS.log, with an older rollover at CBS.persist.log beside it. The summary block near the end is the part to read: it counts detected corruption and repaired corruption by category, so a run that detected two problems and repaired one tells you immediately that something is still outstanding.

Above the summary, individual lines name the components. Microsoft’s worked example shows lines marked CSI Payload Corrupt, CBS MUM Missing and CSI Manifest Corrupt, each naming the component and, where relevant, the file. One of the manifest entries in that example is marked “(Fixed)” and another is not — which is exactly the distinction the summary counts.

From there Microsoft documents an advanced route. Read the Update Build Revision number out of the component name, match it against the Windows update history page for your version to find the KB number, download that update from the Microsoft Update Catalog, extract the .msu and .cab files, copy the correct versions of the corrupted files into a folder such as C:\temp\Source, and re-run DISM with /Source pointing at it and /LimitAccess. Verify afterwards with DISM /Online /Cleanup-Image /ScanHealth and check CBS.log again.

That procedure works, and it is also more than most people need or want. If the log names a handful of components and the machine is otherwise healthy, it is worth doing. If the log is full of corruption, rebuilding is the better use of an afternoon.

Repairing one named component beats reinstalling Windows. Repairing forty is a signal to stop repairing.

5. When to stop repairing and rebuild

An in-place upgrade — running setup from installation media for the version you already have, choosing to keep files and apps — replaces the component store wholesale while leaving your files, settings and installed applications in place. Microsoft does not name it in the update-repair article, so treat it as our recommendation rather than a documented step: it is the last thing worth trying before a clean install, and it is far less disruptive than one.

It is not a clean install and it does not wipe anything, but it is a full Windows setup run, so treat it accordingly: back up first, plug the laptop in, and give it an hour. Use media matching your installed version and edition.

Before committing to that, confirm the store is genuinely the problem rather than a single update. If exactly one update fails and everything else installs cleanly, the fault is more likely to be that update’s package. Microsoft’s article on the related 0x800F0831 documents that case directly: the update being installed requires the manifest of a previous update package, and the remedy is to find that missing package in the Microsoft Update Catalog, download it and install it. That is a much smaller operation than rebuilding.

6. What to establish before asking for help

Three facts do most of the work. Whether one update fails or several. What DISM reported verbatim, including whether the restore operation completed successfully. And what the summary block in CBS.log counted as detected versus repaired.

Check whether the machine is managed, because it changes the diagnosis. A PC pointed at WSUS may be unable to obtain repair content at all, which turns a store repair into a policy question — and that is your administrator’s to answer, not something to work around from the command line.

When you contact Microsoft, say which updates are failing and since when, the exact DISM and SFC commands you ran and what each reported, the detected and repaired counts from CBS.log, your Windows version and build from winver, and whether the device is domain-joined or WSUS-managed. Those five answers separate a repairable store from a blocked repair source from a single broken package.

Frequently asked questions

Sources and review notes

Checked on September 8, 2026. Compiled by Glitchary from Microsoft’s Learn documentation on fixing Windows Update corruption and installation failures. That article is written for support agents and IT professionals, and the advanced CBS.log procedure it describes is genuinely advanced — the DISM and SFC sequence in section 2 is what most people need. Command syntax and log locations differ on older Windows versions. Glitchary is independent of Microsoft.

• Microsoft: fix Windows Update corruptions and installation failures
• Microsoft: error 0x800F0831 when installing an update