Fix 0XC0150012: SXS system default activation context empty

When this error shows up

You're running a 64-bit application on Windows 7, 8.1, or 10 — maybe an old Delphi app or a .NET 3.5 tool — and it crashes at launch with STATUS_SXS_SYSTEM_DEFAULT_ACTIVATION_CONTEXT_EMPTY (0XC0150012). The event log entry says "The activation context of the system default assembly could not be generated." It's not a hardware failure. It's a Windows side-by-side (WinSxS) manifest problem.

Common triggers:

After uninstalling or updating .NET Framework 3.5 or 4.x
After a Visual C++ redistributable install or repair
After a Windows Update that patched a side-by-side assembly file
Sometimes after running a registry cleaner that stripped WinSxS entries

I've seen this most often on Windows 7 SP1 and Windows 10 1803–20H2 builds. The app itself is fine — it's the environment that's broken.

Root cause

What's actually happening here is that Windows uses the WinSxS folder to store multiple versions of shared DLLs and manifests. When an application requests the system default activation context (basically a set of assembly bindings), the Windows SXS subsystem looks for a specific manifest — usually system.windows.manifest or a policy file. If that manifest is missing, corrupted, or the catalog file (.cat) that signs it is out of sync, the context fails to build, and Windows throws 0XC0150012.

The reason you get this on a per-app basis is that the app's manifest (embedded or sidecar) references the system default context. The system context is a singleton — if it's broken, every app that relies on it breaks.

Most common culprit: a .NET 3.5 installation that partially failed, leaving the system.windows.manifest in the WinSxS store but missing its associated system.windows.cat file. The same happens when a Visual C++ redistrip corrupts the Microsoft.Windows.Common-Controls manifest.

The fix

Skip the usual "run SFC" advice. SFC alone won't fix this because the corruption isn't in a system file — it's in the manifest catalog linkage. You need to force the SXS subsystem to rebuild the context.

Re-register the SXS component
Open an elevated command prompt (Run as Administrator). Run:
```
regsvr32 /u sxs.dll
regsvr32 sxs.dll
```
This unregisters and re-registers the side-by-side loader DLL. It forces the system to flush the cached activation contexts. Don't skip the unregister step — that's what clears the stale state.
Repair .NET 3.5
If the error involves a .NET app, repair the entire .NET 3.5 stack (which includes 2.0, 3.0 SP2, and 3.5 SP1). Run:
```
dism /online /enable-feature /featurename:NetFx3 /all /source:D:\sources\sxs /limitaccess
```
Replace D: with your Windows installation media drive. If you don't have media, remove the /source and /limitaccess flags — DISM will pull from Windows Update.
DISM and SFC in that order
DISM first — it fixes the component store itself. SFC second — it fixes file-level issues against the repaired store.
```
dism /online /cleanup-image /restorehealth
sfc /scannow
```
The reason step 3 works after step 2 is that DISM rebuilds the WinSxS catalog entries that SFC depends on. Running SFC first would waste time and often fail.
Check the specific app's manifest
If the app has a sidecar manifest file (e.g., yourapp.exe.manifest), open it in Notepad. Look for the dependentAssembly section that references Microsoft.Windows.Common-Controls or System.Windows.Forms. Sometimes the version string is wrong — like 6.0.0.0 when the system has 6.1.0.0. Edit the version to match what's actually in C:\Windows\WinSxS\Manifests. If you're not sure, delete the sidecar manifest temporarily — Windows might fall back to a built-in default.
Last resort: reset WinSxS
On Windows 10, you can run:
```
dism /online /cleanup-image /startcomponentcleanup
```
This removes superseded versions of WinSxS components. I've seen it fix a stuck system context. Only do this if the other steps didn't work — it can't be undone easily.

If it still fails

Check the Windows Application event log for SXS error details. Look for Event ID 33 or 59 from source "SideBySide". The error message often names the exact manifest file that's missing (e.g., system.windows.manifest or x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.0.0_none_... .manifest).

If the manifest is named but not present in C:\Windows\WinSxS\Manifests, you can extract it from a working machine with the same Windows version and service pack. Copy the file and its corresponding .cat file into the manifest folder, then reboot. That's a hack, but it works when DISM fails.

If none of this helps, you're looking at a corrupt OS install. Consider a repair upgrade (in-place install) using the Windows Media Creation Tool — it preserves apps and data but rebuilds the entire WinSxS store from scratch.