0x8007370B and 0x8007370D: component identity errors in the servicing store

Fix it now

These are side-by-side identity errors: the servicing stack read a component identity string and found something it will not accept. The repair is to rebuild the damaged parts of the component store from a clean source, then let system file checking pick up anything left.

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

1. Read what ScanHealth reports before running the repair. If it says the store is repairable, RestoreHealth is the right next step. If it says no corruption was detected, the fault is elsewhere and rebuilding will not help.
2. If RestoreHealth cannot fetch what it needs, give it a source of the same version and build: DISM /Online /Cleanup-Image /RestoreHealth /Source:D:\sources\install.wim:1 /LimitAccess.
3. Run sfc /scannow after DISM, not before. System file checking repairs from the component store, so it can only fix things once the store itself is sound.
4. Retry the update or the feature install that failed, and read the new result rather than assuming.

The source must match the installed version, edition and architecture. An install.wim from an earlier feature update is the most common reason a repair with an explicit source still fails.

If the update installs you can stop here. If not, the next section explains what an identity actually is and why these codes are not the same as a corrupt manifest.

Why it happens

Windows keeps its components in a side-by-side store under %WinDir%\WinSxS, and every component in it is addressed by an identity: a name, a processor architecture, a version, a language and a public key token. Component-based servicing works almost entirely in terms of those identities. It resolves them, compares them, and builds the transaction that installs an update out of them. If it cannot read one, nothing later in the transaction can proceed.

That is what these codes report, and it is a narrower statement than the one usually attached to them. 0x8007370B is Win32 14091, ERROR_SXS_INVALID_IDENTITY_ATTRIBUTE_NAME: the name of an attribute in an identity is not within the legal range. 0x8007370A is Win32 14090, ERROR_SXS_INVALID_IDENTITY_ATTRIBUTE_VALUE, the same problem one level down, where the attribute is named correctly but its value is out of range. 0x8007370D is Win32 14093, ERROR_SXS_IDENTITY_PARSE_ERROR: the identity string itself is malformed.

None of the three says a manifest file is corrupt or truncated. That is a different failure with different codes, and the distinction changes what you check. Two other codes in this family do point at document content: 0x800705B9 is Win32 1465, ERROR_XML_PARSE_ERROR, Windows was unable to parse the requested XML data, and 0x80070246 is Win32 582, ERROR_ILLEGAL_CHARACTER. If you are seeing one of those, you are looking at bad bytes in a file. If you are seeing the 1409x codes, you are looking at an identity the stack cannot make sense of.

Full reference

The identity codes and their neighbours

0x80073712 is not in the list this article is named after, but it is the code most readers meet next, and it is the one that says the store as a whole is inconsistent rather than one identity being unreadable. If you are collecting evidence for a decision about whether to repair or rebuild, that is the code that tips the balance.

Reading the servicing log

%WinDir%\Logs\CBS\CBS.log is where component-based servicing writes what it did and why it stopped. It is verbose and it is worth the trouble, because it names the component that failed rather than leaving you with a hex value. Search it for the hex code, then read upwards from the first hit to find the package and component being resolved at the time.

Keeping the store healthy afterwards

Component store growth is normal and is not itself a fault, but a store that has never been cleaned carries every superseded version of every component. Dism.exe /online /Cleanup-Image /StartComponentCleanup removes superseded components on a supported schedule and is safe to run on a working machine.

/ResetBase removes all superseded versions of every component in the store. After it, installed updates cannot be uninstalled. Run it only when you are certain you will not need to roll anything back.

When repair keeps failing

• Confirm the source really matches. Version, edition and architecture all have to line up, and install.esd from a consumer download is not interchangeable with install.wim from other media.
• Check free space on the system volume. A repair that cannot expand what it needs fails in ways that look like corruption.
• Rule out third-party disk filters. Encryption and backup products insert themselves between servicing and the file system, and removing them for the duration of a repair is a fair test.
• Look at the disk itself. Repeated store corruption on the same machine, especially after a clean rebuild, is a strong hint that the storage is failing rather than the software.
• On a managed client, make sure the repair is allowed to reach a source at all. A policy that pins servicing at a server holding no repair content turns every repair into a source failure.

Every code this article covers

Confirm the fix worked

1. DISM /Online /Cleanup-Image /ScanHealth reports no component store corruption.
2. sfc /scannow completes and finds no integrity violations, or repairs them and says so.
3. The update or feature install that produced the code now completes.
4. CBS.log shows the new transaction reaching a successful conclusion rather than stopping at the same component.

Questions people ask about this