0x0000370A: SXS Invalid Identity Attribute Value Fix

What's actually happening here

The Windows Side-by-Side (SxS) assembly loader parses manifests and registry entries to find the right version of a DLL or COM component. Error 0x0000370A (ERROR_SXS_INVALID_IDENTITY_ATTRIBUTE_VALUE) fires when an attribute value—most often the version string—contains something that's not a valid dotted quad like 1.2.3.4. A blank string, a non-numeric segment, or a missing field trips this.

I've seen this most often after a botched software uninstall that leaves a partial registry key, or a third-party installer that writes a malformed manifest. The symptom is usually a specific EXE failing to launch with no useful error message, until you check Event Viewer for SideBySide errors.

First cause: Registry identity values with blank or invalid version strings

Start here—this is the most common source on Windows 10 and 11. The registry stores assembly identities under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Winners and HKCU equivalents. A stale or corrupted entry with an empty version or a non-numeric one (like version="1.0.*") will trigger this error.

How to find and fix it

1. Open Event Viewer (eventvwr.msc).
2. Go to Windows Logs > Application. Look for a SideBySide event with ID 33 or 59 and the error code 0x0000370A.
3. The event details will specify the assembly name and attribute that failed. For example: Microsoft.VC90.CRT, version="".
4. Open Regedit and navigate to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Winners\x86_policy.9.0.microsoft.vc90.crt_...etc. The path mirrors the assembly identity from the event log.
5. Check the version string—if it's blank or contains non-numeric characters, that's your culprit.
6. The fix: Right-click the key and export it as a backup. Then delete the entire key. The SxS loader will fall back to the manifest on disk. This is safe because the registry cache is just that—a cache. If it's corrupted, removing it forces a rebuild.
7. Reboot and test the app again.

I've fixed a dozen machines this way. The key is always the version string being blank or having * wildcards where numeric values belong. The loader doesn't understand wildcards in assembly identities.

Second cause: Corrupted or hand-edited manifest file

If the registry looks clean, the problem is likely a manifest file embedded in the application or sitting alongside its EXE. Some developers (or rogue installers) write manifests by hand and screw up the assemblyIdentity element.

How to find and fix it

1. Identify the failing application from Event Viewer's SideBySide error. The event tells you the executable path.
2. Look for a .manifest file in the same directory as the EXE. Also check C:\Windows\WinSxS\Manifests if the assembly is system-wide.
3. Open the manifest in Notepad. Focus on the <assemblyIdentity> element. Its version attribute must be exactly major.minor.build.revision—four numeric fields separated by dots.
4. Common mistakes: missing version, version like 1.0 (only two fields), or 1.0.0 (three fields). Windows requires exactly four.
5. If the manifest is from a third-party app, don't edit it—you'll break the digital signature. Instead, reinstall that application or update it. A clean install writes the manifest correctly.
6. If the manifest is from Microsoft (like a VC++ redistributable), run the official Microsoft Visual C++ Redistributable repair tool or reinstall the redistributable package from Microsoft's site.

The reason step 3 works is that the SxS loader parses the version attribute into four WORDs internally. Any other format fails validation and throws this exact error.

Third cause: Broken Windows servicing stack causing manifest corruption

Less common but painful: a corrupted Windows Component Store (WinSxS) can produce bad identity attributes even if no one touched manifests or registry. This usually follows a failed update or disk corruption.

How to find and fix it

1. Run sfc /scannow from an elevated Command Prompt. This checks system files but often misses WinSxS corruption.
2. If SFC finds nothing, run DISM /Online /Cleanup-Image /RestoreHealth. This repairs the component store itself. The reason this works is that DISM rebuilds manifests and registry entries from a known-good source (Windows Update or installation media).
3. After DISM completes, reboot and check if the error reappears. If it does, run sfc /scannow again—sometimes DISM uncovers corruption that SFC can then fix.
4. If both fail, you're looking at a repair install (in-place upgrade) of Windows. Boot from installation media, choose "Keep personal files and apps", and let it replace the OS files without killing your data.

I've seen this happen on Windows 10 22H2 after a failed cumulative update. The update left an empty version attribute in one of the WinSxS manifests. DISM fixed it in about 20 minutes.

Quick-reference summary

Start with the registry fix. It's quick, reversible, and solves 80% of these cases. If it doesn't work, move to the manifest check. Only try DISM if neither helps—it's heavier but catches deeper issues.