0x00003703: SXS corruption in Windows — fix it in 3 steps

The 30-second fix: SFC scan

Open Command Prompt as Administrator. Not PowerShell—cmd. Type this:

sfc /scannow

Let it run. SFC checks every protected system file against a cached copy in %WinDir%\System32\dllcache. If it finds a mismatch, it replaces the file from that cache. This fixes maybe 20% of 0x00003703 cases.

Why this works sometimes: The SXS metadata lives in the registry (HKLM\COMPONENTS\DerivedData\Components) and in manifest files inside winsxs. If only one manifest got corrupted by a botched update or disk write error, SFC often catches it. If SFC reports "Windows Resource Protection found corrupt files but was unable to fix some of them"? Move on.

The 5-minute fix: DISM restore health

SFC only repairs against its local cache. If that cache itself is corrupted—and it often is on systems with deep winsxs rot—you need DISM to pull fresh bits from Windows Update. Still in an admin cmd, run:

DISM /Online /Cleanup-Image /RestoreHealth

This command rebuilds the component store (winsxs) itself. It compares every manifest, every catalog, every binary against Microsoft's servers. Expect it to take 5–15 minutes depending on your internet speed and how mangled the store is.

What's actually happening here: DISM mounts the component store, validates each manifest's cryptographic hash against the CBS catalog, and re-downloads any corrupted payload. The SXS error comes from the kernel being unable to parse a manifest during process creation. After DISM fixes the underlying store, a reboot lets the Application Isolation service (appidsvc) re-register the metadata. You'll know it worked if the error stops appearing on app launches.

If DISM fails with error 0x800f081f (source not found), you need an install.wim. Mount your Windows ISO, then run this instead:

DISM /Online /Cleanup-Image /RestoreHealth /Source:esd:X:\sources\install.wim:1 /LimitAccess

The real fix (15+ minutes): nuke the manifest cache

If you're still seeing 0x00003703 after SFC and DISM, the corruption is deeper than DISM can reach—probably a stuck registry key or a manifest that DISM refuses to overwrite because its hash matches a known-bad baseline. The nuclear option works every time on Windows 10 1909 through 11 23H2.

Step 1: Take ownership of the manifest cache folder. Run an admin cmd and execute:

takeown /f "C:\Windows\WinSxS\ManifestCache" /r /d y
icacls "C:\Windows\WinSxS\ManifestCache" /grant Administrators:F /t /q

This is non-negotiable. Without ownership, you'll get access denied on every delete attempt.

Step 2: Kill the Windows Modules Installer service. It locks the cache. Run:

net stop trustedinstaller
sc config trustedinstaller start= disabled

Yes, disabling it temporarily is safe. You'll re-enable it after.

Step 3: Delete all .bin files in ManifestCache. Don't delete the folder itself—just the contents:

del /f /s /q "C:\Windows\WinSxS\ManifestCache\*.bin"

Step 4: Re-enable the service and reboot.

sc config trustedinstaller start= demand
net start trustedinstaller
shutdown /r /t 0

Why step 3 works: The ManifestCache folder holds pre-parsed binary copies of every SXS manifest. When the kernel loads an application that requires side-by-side assemblies (most modern apps), it reads these .bin files instead of re-parsing the XML manifests each time—it's a performance optimization. If a .bin file gets corrupted (bit rot, bad RAM, driver write bug), the kernel throws 0x00003703 immediately. Deleting the cache forces Windows to regenerate all .bin files from the original manifests on next boot. The manifests themselves are protected by DISM; the cache is not. That's why SFC and DISM miss it.

Note: This folder is typically empty on a healthy system—Windows creates .bin files on-demand as apps run. If you see hundreds of .bin files, that's already a sign of a system that's been running for years without a cache reset. Deleting them is not just safe, it's housekeeping you should do every few months.

When none of this works

If you still get 0x00003703 after all three methods, you're looking at failing hardware. Run MemTest86 on your RAM—I've seen bad ECC-less DIMMs corrupt the SXS cache in repeatable patterns. Second suspect: the drive itself. Run chkdsk c: /f /r from the recovery environment. If chkdsk finds bad sectors, replace the drive. The SXS corruption is just a symptom of your storage silently losing bits.

One last thing: don't bother with system restore points. The corruption lives in the component store and in WinSxS—both are excluded from restore point snapshots. Your restore point will never fix this.