0x80073712 and 0x800F081F: component store corruption blocking updates

Fix it now

0x80073712 is ERROR_SXS_COMPONENT_STORE_CORRUPT: the component store is in an inconsistent state, so every later update fails at verification. 0x800F081F is CBS_E_SOURCE_MISSING, the follow-on complaint that the files needed to repair it cannot be found.

DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

1. RestoreHealth can sit at one percentage for a long time. Leave it alone unless the disk and CPU have been idle for a long stretch; interrupting it leaves the store worse than it found it.
2. If it returns 0x800F081F, it needs a source. Mount an ISO of the same edition and build and rerun it as DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:D:\sources\install.wim:1 /LimitAccess.
3. Check the index first with DISM /Get-WimInfo /WimFile:D:\sources\install.wim and pick the one whose edition matches the machine.
4. Reboot, then reinstall the update that was failing.

/LimitAccess prevents DISM contacting Windows Update for repair of online images. Use it while diagnosing, so a silent fallback cannot make you think your source worked when it was ignored.

If ScanHealth now reports no corruption and the update installs, you are finished. If the repair itself fails, the next section explains what the store is checking and why your source is being rejected.

Why it happens

Everything Windows installs lives in the component store under WinSxS, described by manifests and projected into place where the running system expects it. Servicing does not copy files blindly. Before it applies a change it verifies that the components already present match what their manifests say, because an update is expressed as a change against a known starting state.

When a file has been deleted, replaced by something else, or damaged on disk, that verification fails and the transaction stops. 0x80073712 is the store reporting itself inconsistent, and because it is the store rather than the package, the same code follows you from one month’s update to the next. There is nothing wrong with the update you are trying to install, and downloading it again changes nothing.

Repair works by fetching known-good copies of the affected components. By default DISM asks Windows Update for them. Where the machine has no route to Windows Update, or policy sends it to an internal update server that carries no repair payload, DISM has nothing to work with and reports CBS_E_SOURCE_MISSING. Supplying an image of the same build solves that directly, and it is the step most people get wrong on the first attempt.

The remaining codes in this family are side-by-side servicing errors with their own published meanings. 0x80073701 is a referenced assembly that could not be found, and Microsoft’s own mitigation for it is DISM /RestoreHealth followed by sfc /scannow. 0x800736B5 is a manifest with one or more syntax errors. 0x80073715 is subtler and worth knowing: two manifests with identical identities but different contents, which is what you get when a component has been replaced by a build that was never meant to be there.

Full reference

Getting the repair source right

This is where most repairs fail. The source has to be the same edition and architecture, and Microsoft’s rule on patch level is one-directional: the source must be patched to at least the level of the target. A target patched higher than the source needs updated files the source does not contain, and DISM reports the source as unusable rather than explaining why.

DISM /Get-WimInfo /WimFile:D:\sources\install.wim

rem where the media ships install.esd rather than install.wim
DISM /Export-Image /SourceImageFile:D:\sources\install.esd /SourceIndex:1 /DestinationImageFile:C:\temp\install.wim /Compress:max /CheckIntegrity

What each switch actually does

The codes that travel with these two

Reading the servicing log

The code tells you a class of failure. %windir%\Logs\CBS\CBS.log tells you which component. Search it for the failure time and read backwards a few hundred lines; servicing writes the name of the component it was verifying immediately before it gives up. The DISM log sits beside it under %windir%\Logs\DISM and records what the repair attempted and what source it used, which is how you confirm that /Source was honoured rather than ignored.

When repair will not take

• If DISM reports the image as unserviceable, stop repairing and plan an in-place upgrade with media patched to at least the machine’s level. Microsoft’s own guidance for this family of codes ends at an in-place upgrade.
• If the same component fails repeatedly after a successful repair, look for something replacing it: a security product restoring a quarantined file, or a vendor utility that installs its own copy of a system binary.
• If several unrelated components fail at once, treat the disk as a suspect before the store.
• Do not copy system files from another machine. Versions and hashes have to match what the manifests expect, and a hand-copied file usually breaks the next update as well.

An in-place upgrade rewrites the operating system. Take a full backup first, confirm you hold any disk encryption recovery keys, and expect a long reboot cycle during which the machine is unusable.

Every code this article covers

Confirm the fix worked

1. Run DISM /Online /Cleanup-Image /ScanHealth and confirm no component store corruption is detected.
2. Run sfc /scannow and confirm it reports no integrity violations.
3. Reinstall the update that was failing and confirm it completes and survives a reboot.
4. Check Update history and confirm the entry reads as installed rather than failed.
5. Read the tail of the DISM log and confirm the repair used the source you intended.

Questions people ask about this