STATUS_SXS_FILE_HASH_MISMATCH (0xC015001B): Fix Side-by-Side Hash Failures

You double-click an app — maybe Photoshop, a Steam game, or an old VB6 tool from 2004 — and instead of launching, Windows spits out STATUS_SXS_FILE_HASH_MISMATCH with the code 0XC015001B. Sometimes it shows up in Event Viewer as a SideBySide error 33. Sometimes it's an MSI installer dying halfway through. Either way, the cause is the same, and it's not the app's fault.

What's actually happening here is the WinSxS (Windows Side-by-Side) component store tracks every shared DLL and its expected cryptographic hash in a manifest. Before loading a DLL, the loader compares the file on disk against the hash in the manifest. If they don't match — even by one bit — you get 0xC015001B. The loader is doing exactly what it was designed to do: refusing to run a file that's been altered from what Microsoft shipped.

Something changed a file it shouldn't have. Here's how to fix it, in order of how often each cause is the real one.

Cause 1: Component store corruption (the most common)

Nine times out of ten, a file inside C:\Windows\WinSxS got corrupted. Bad RAM during an update, an interrupted Windows Update, a disk sector going bad, or an antivirus quarantine that grabbed a system DLL and left a stub behind. The manifest still has the original hash; the file doesn't match anymore.

The fix is DISM with the /RestoreHealth switch, then SFC. Run them in an elevated Command Prompt or PowerShell — not the normal one. If you skip the elevation, DISM runs and reports nothing useful.

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

The reason step 3 works is that /RestoreHealth reaches out to Windows Update and pulls fresh copies of any component whose hash doesn't match. SFC alone can't do this — it verifies signatures but can't always source a clean replacement. Run DISM first, always.

If DISM fails at 20% or 40% with "source files could not be found," you're on a machine without internet or one with a WSUS policy blocking Windows Update access. Point DISM at a matching ISO as a repair source:

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

Replace E:\ with the drive letter of the mounted ISO. The :1 is the image index — use dism /Get-WimInfo /WimFile:E:\sources\install.wim if you need to confirm which index matches your edition.

Cause 2: A third-party tool or AV quarantined a WinSxS DLL

This is the one people miss. Bitdefender, Malwarebytes, and a handful of older endpoint agents have all shipped versions that flagged legitimate WinSxS DLLs as suspicious — usually the VC++ 2005/2008 runtimes that ship pre-installed on enterprise images. The AV quarantines the file, Windows replaces it with a zero-byte placeholder or leaves nothing at all, and the next app that loads the runtime hits 0xC015001B.

A real trigger I've seen: a Windows 10 21H2 machine running an older Kaspersky Endpoint build. Every launch of a legacy Line-of-Business app failed with 0xC015001B, but sfc /scannow reported "no integrity violations" because the AV had already replaced the file with a clean-looking stub.

Check your AV's quarantine log for anything under C:\Windows\WinSxS\ or C:\Windows\System32\. Restore from quarantine, then exclude the WinSxS folder from real-time scanning. That folder is system-managed and shouldn't be touched by anything except Windows itself.

Then re-run DISM /RestoreHealth. Even if the AV restored the file, its hash may not match — DISM will overwrite it with a known-good copy.

If you see the error only on one user account and not others, the problem isn't WinSxS. That's a per-user issue — usually a bad side-by-side manifest in the app's own folder or a broken %LOCALAPPDATA% cache. Skip to Cause 3.

Cause 3: A stale or hand-edited app manifest

Less common on modern Windows, but very common on machines that run old line-of-business software. The app ships its own .manifest file declaring a specific version of the VC++ runtime (e.g., Microsoft.VC80.CRT version 8.0.50727.762). Windows looks up that version in WinSxS, finds a different build (like 8.0.50727.6195), and the hash check fails because the manifest expects a specific revision.

The symptom is specific: the error names a runtime like Microsoft.VC90.CRT or Microsoft.VC80.MFC. Fix is to install the matching Redistributable — yes, the exact year. Installing VC++ 2015-2022 won't satisfy an app that demands VC++ 2008 SP1.

Grab the right one from Microsoft's official download page. Don't grab it from a random DLL site — you're already debugging a hash mismatch, the last thing you need is a fake runtime. For 32-bit apps on 64-bit Windows, install both the x86 and x64 versions.

If the app has its own side-by-side manifest you can edit (rare, but some in-house tools do), check for a manually pinned version or publicKeyToken that no longer matches what's installed. Removing the pinned reference and letting Windows pick the current runtime usually clears it.

When none of that works

Run this and look for the failure in the Microsoft-Windows-SideBySide channel — it names the exact component and the expected versus actual hash.

wevtutil qe "Microsoft-Windows-SideBySide/Operational" /c:20 /rd:true /f:text

If the component is a Microsoft runtime, DISM should have caught it. If it's a third-party component (some CAD suites and industrial software ship their own side-by-side assemblies), the repair has to come from the vendor's installer. Reinstall the app using its original media and choose the repair option.

Last-resort move for a machine that's beyond patching: an in-place upgrade repair install using a matching Windows ISO. This rebuilds WinSxS without touching your files or apps. It takes an hour and needs a clean ISO, but it's faster than a clean install and works when DISM keeps failing.

Quick reference

Start with DISM. If that reports clean and the error persists, check the SideBySide event log — it'll tell you exactly which component failed and end the guessing game.