DISM RestoreHealth fails with 0x800F081F or 0x80073712 during recovery

Fix it now

0x800F081F is CBS_E_SOURCE_MISSING – the source for the package or file was not found. 0x80073712 says the component store is in an inconsistent state. Both are fixed the same way: give DISM a matching copy of Windows to repair from, and stop it consulting Windows Update when policy will not let it.

winver
dism /Get-WimInfo /WimFile:E:\sources\install.wim
dism /Online /Cleanup-Image /RestoreHealth /Source:WIM:E:\sources\install.wim:3 /LimitAccess
sfc /scannow

1. Note the edition, version and build from winver. The repair source has to match that installation, and Microsoft’s guidance is to use RTM media patched to the latest cumulative update.
2. Read the index list from Get-WimInfo and pick the index whose name matches your edition. Pro, Home, Education, Standard and Datacenter all sit at different indexes.
3. Run RestoreHealth with /Source pointing at that index and /LimitAccess to stop DISM using Windows Update.
4. Where the media ships install.esd instead of install.wim, the same command works with /Source:ESD:E:\sources\install.esd:<index> /LimitAccess.
5. Follow with sfc /scannow, restart, and retry whatever originally failed.

A source at a lower patch level than the machine is the case that fails. Microsoft warns that a target patched to a higher level than the source may fail when adding features or repairing, so if in doubt patch the machine and use current media rather than older media.

If ScanHealth now reports no corruption, you are done. If the same code comes back with a matching source in place, the next section explains what else it can be.

Why it happens

Every Windows component lives in the component store under C:\Windows\WinSxS, alongside manifests describing what each one should look like. RestoreHealth walks that store, compares reality against the manifests and replaces anything that does not match. What it cannot do is invent a replacement: if the payload is missing from the store as well, it has to fetch a copy from somewhere else.

By default that somewhere else is Windows Update, and Microsoft documents it as the default repair source. Whether the machine may use it is decided by policy – the Group Policy setting Specify settings for optional component installation and component repair, under Computer Configuration, Administrative Templates, System. On a home machine this works silently and nobody ever sees the code. On a managed machine the policy is often configured so that it does not, which is why 0x800F081F turns up on domain-joined machines that are otherwise perfectly healthy.

0x80073712 is a different statement about the same store: ERROR_SXS_COMPONENT_STORE_CORRUPT, the component store has been corrupted, rather than a payload being absent. The remedy is identical but it should change your confidence afterwards. A store that keeps re-reporting corruption after a successful repair is telling you something else is wrong, usually a disk or memory fault.

The two remaining codes are often lumped in and should not be. 0x800700B7 is ERROR_ALREADY_EXISTS – cannot create a file when that file already exists – which during servicing usually means an operation is already in progress or a stale mount point is in the way. 0x80073713 is ERROR_ADVANCED_INSTALLER_FAILED: an advanced installer failed during setup or servicing. That is not a missing source and not store corruption; it is a specific installer failing, and the CBS log is where its name appears.

Full reference

The switches that matter

Choosing a repair source

Microsoft documents four shapes of source: a mounted image such as c:\mount\Windows, a running Windows installation shared over the network, a side-by-side folder such as z:\sources\SxS, and a WIM file addressed with the Wim: prefix and an index. The important constraint is not the shape but the patch level: use RTM media rather than refresh media, and ensure the source is patched to the latest cumulative update. A target patched higher than its source is the combination Microsoft warns about.

The four codes, kept apart

Reading the logs when the code is not enough

DISM writes to C:\Windows\Logs\DISM\dism.log and the servicing stack writes to C:\Windows\Logs\CBS\CBS.log. The CBS log is the one that names the specific component that could not be found or repaired, and it is where an advanced installer failure identifies itself. To extract the system file checker’s findings, run findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log > %userprofile%\Desktop\sfcdetails.txt and read the result.

Setting a repair source for a fleet

1. Extract install.wim from media matching your current build, patched to the latest cumulative update.
2. Place it on a read-only share reachable from the machines you manage.
3. Open the Group Policy setting Specify settings for optional component installation and component repair, under Computer Configuration, Administrative Templates, System.
4. Set the alternate source file path to the share, using the Wim:\\server\share\install.wim:<index> form where you need a specific edition.
5. Decide separately whether machines may contact Windows Update for repair, and set that in the same policy rather than leaving it implicit.

Refresh the share when you move to a new build. A source that was correct in January is the under-patched source that fails in July, and the failure looks identical to having no source at all.

Every code this article covers

Confirm the fix worked

1. dism /Online /Cleanup-Image /ScanHealth reports no component store corruption.
2. sfc /scannow reports no integrity violations.
3. The update, feature installation or reset that originally failed now completes.
4. C:\Windows\Logs\CBS\CBS.log records no further errors after the repair.
5. On a managed estate, a second machine repairs from the same source without a policy change.

Questions people ask about this