Fix ERROR_SXS_INCORRECT_PUBLIC_KEY_OKEN 0x370F

Cause #1: Corrupted .NET Framework installation (most common)

I've seen this exact error on Windows 10 and Server 2016/2019 more times than I can count. The culprit here is almost always a half-broken .NET Framework 3.5 or 4.x installation. A Windows update goes sideways, or someone uninstalled .NET with a third-party cleaner, and now the manifest files in C:\Windows\WinSxS point to public key tokens that don't match the actual assemblies.

You'll notice this when you try to launch a legacy app or a PowerShell script that depends on .NET. The error text says "The public key token does not correspond to the public key specified" — that's your smoking gun.

Fix: Run DISM and SFC first

Don't bother with manual registry edits. Start with the built-in repair tools. Open an elevated Command Prompt (right-click → Run as administrator) and run these commands in order:

dism /online /cleanup-image /restorehealth
sfc /scannow

DISM will take 10-20 minutes. Let it finish. SFC will fix any corrupted system files that DISM couldn't reach. Reboot after both complete, then try your app again. This clears the error in roughly 60% of cases.

If that doesn't do it: Repair .NET Framework

The next step is to repair the .NET Framework itself. Download the .NET Framework Repair Tool from Microsoft (it's a standalone exe, about 10 MB). Run it and let it do its thing. It will re-register all the side-by-side assemblies and fix the key token mismatches.

For Server 2016/2019, you can also remove and re-add the .NET feature via Server Manager:

1. Go to Server Manager → Manage → Remove Roles and Features.
2. Uncheck .NET Framework 3.5 Features and .NET Framework 4.x Features.
3. Reboot, then re-add them using the same wizard.

This is heavy-handed, but it works when the Repair Tool fails. I've had to do it twice in five years — it's your nuclear option.

Cause #2: Corrupt Windows Update or pending reboot

Another common scenario: Windows Updates are mid-install, or the update cache is corrupted. This leaves WinSxS in a state where the public key tokens don't match because the update didn't finish applying.

You'll see this right after a failed cumulative update, or if you've been deferring updates for weeks and finally let them run.

Fix: Clear the update cache and force a clean install

Stop the Windows Update service, delete the cache, then restart the service. Here's the command block (run as admin):

net stop wuauserv
rmdir /s /q C:\Windows\SoftwareDistribution\Download
net start wuauserv

After that, check for pending reboots in the registry:

reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired"

If that key exists, reboot — even if Windows doesn't prompt you. Then run wuauclt /detectnow (on older versions) or just check Windows Update manually.

One thing I learned the hard way: never kill the Windows Update service mid-install. If you did that, this is your fix.

Cause #3: Third-party software messing with SxS manifests

Less common, but I've seen it — antivirus tools (looking at you, older McAfee and Norton versions) that quarantine or alter DLLs in C:\Windows\WinSxS. Also, some "optimizer" tools that disable side-by-side execution. The error pops up when your app tries to load a manifest from a path that's been tampered with.

Fix: Check for quarantined files and re-register the assembly

First, check your AV's quarantine log. If you see anything like system32\win32k.sys or winsxs\manifests\*.manifest — restore it. Then re-register the .NET assemblies that are likely involved:

cd C:\Windows\Microsoft.NET\Framework64\v4.0.30319\
aspnet_regiis.exe -i

That's for 64-bit apps. For 32-bit, use Framework instead of Framework64. If you're still stuck, check the event log under Applications and Services Logs → Microsoft → Windows → SideBySide. It'll tell you the exact assembly name and expected key token — that's gold.

Then use PowerShell to verify the assembly's public key token:

[System.Reflection.AssemblyName]::GetAssemblyName("C:\path\to\your.dll").FullName

Compare that token to the one in the manifest. If they don't match, you've got a file mismatch — replace the DLL from a known-good source (like the original installer).

Quick Reference Table

The key takeaway: don't jump into registry hacks. Run DISM first, then the .NET Repair Tool. That fixes 9 times out of 10. If you've got a weird case, post the SideBySide event log in a forum — the exact assembly name is the clue that'll save you hours.