Fix STATUS_SXS_PROCESS_DEFAULT_ALREADY_SET (0xC015000E) on Windows

You double-click an app, and instead of opening, it dies with 0xC015000E. Maybe it's a game launcher, an older business tool, or a setup utility. The Windows Event Log shows STATUS_SXS_PROCESS_DEFAULT_ALREADY_SET and nothing else useful. What's actually happening here is that a process tried to call SetProcessDefaultActCtx when a default activation context was already set. Windows won't let a process swap its default activation context after it's been established. One call is fine. Two calls crash the process.

The activation context is what the side-by-side (SxS) subsystem uses to resolve which version of a DLL to load — say, comctl32.dll version 6 versus version 5. Once a process picks one, that choice is locked. So the question isn't really "how do I fix SxS?" The question is which piece of code is calling CreateActCtx or SetProcessDefaultActCtx a second time.

Cause 1: A third-party DLL is setting its own activation context

This is the one you'll hit 80% of the time. Some component loaded into your process — a shell extension, a printer driver helper, an input method editor, an antivirus hook — was written to set its own activation context on load. If the host app already set one, boom. 0xC015000E.

A classic real-world trigger: you install an older CAD or accounting package that ships a manifest-dependent DLL, then also install a newer shell extension that does the same thing. Either one alone is fine. Together, the second call fails. The error often appears only when the app is launched from Explorer but works when launched from cmd.exe — because Explorer loads different shell extensions than a bare console.

Fix

1. Open Event Viewer → Windows Logs → Application. Find the crash. The faulting module name is usually right there.
2. If the module is a shell extension, run ShellExView (NirSoft) and disable non-Microsoft extensions in batches of five. Relaunch the app between batches.
3. If it's a driver helper or AV hook, check the vendor for an updated build. Older builds of some endpoint agents are notorious for calling CreateActCtx inside DllMain — which is also illegal for other reasons.

You can confirm the second-call theory with a debugger. Attach WinDbg or x64dbg, set a breakpoint on SetProcessDefaultActCtx in KERNELBASE.dll, and watch how many times it fires. Two hit, second one fails.

bp KERNELBASE!SetProcessDefaultActCtx
bp KERNELBASE!CreateActCtxW

Cause 2: A broken or duplicated application manifest

Manifests declare the DLL version dependencies for a process. If a manifest is malformed, or if two manifests end up embedded in the same EXE (say, after a bad patch by an installer), the loader can try to apply the default activation context twice. This shows up a lot with apps packaged by third-party installers that re-embed resources without stripping the old ones.

Another pattern: the app has an external appname.exe.manifest next to the EXE and an embedded manifest. Windows prefers the external one, but some loaders still fire both. Also check appname.exe.local — an old redirection mechanism that can force a second context to load.

Fix

1. Right-click the EXE → Properties → see if there's a Compatibility tab entry forcing an older OS mode. Remove it.
2. Look in the app folder for .manifest and .local files. Move them aside temporarily and retest.
3. If the embedded manifest is corrupt, extract it with Resource Hacker or mt.exe, fix the XML, and re-embed. Compare against a known-good copy from the vendor if you can get one.

mt.exe -inputresource:app.exe;#1 -out:app.manifest
mt.exe -manifest app.manifest -outputresource:app.exe;#1

While you're looking at the manifest, check that dependentAssembly entries reference assemblies that actually exist in C:\Windows\WinSxS. A missing assembly produces a different SxS error, but a manifest with duplicate assemblyIdentity nodes can produce 0xC015000E after a partial load.

Cause 3: Bad Visual C++ runtime or mixed runtime versions

Applications built with Visual Studio usually rely on the VC++ runtime libraries, and those libraries themselves participate in SxS. If you've got a half-installed VC++ redistributable — say, the install was interrupted — you can end up with mismatched msvcr120.dll / msvcp140.dll pairs where the CRT tries to initialize its activation context after the app has already done so.

This tends to surface right after a Windows feature update on Windows 10 22H2 or Windows 11 23H2, when the update refreshes some system DLLs but leaves stale copies in System32 or SysWOW64.

Fix

1. Open Settings → Apps and uninstall every Microsoft Visual C++ Redistributable.
2. Reboot. Yes, actually reboot.
3. Install the latest combined VC++ 2015–2022 x86 and x64 redists from Microsoft. Both, even on 64-bit Windows.
4. Run the app again.

If that doesn't stick, clean the WinSxS store. The real fix is DISM /Online /Cleanup-Image /RestoreHealth, not sfc /scannow — sfc alone won't repair SxS manifests that DISM will. Run sfc after if you want, but DISM first.

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

Note: don't run third-party "SxS repair" tools. They almost always just reinstall the VC++ redist and delete WinSxS entries that weren't the problem. You'll spend more time recovering from that than from the original error.

Quick reference

If you've done all three and it still fails, the app's own code is the problem — it's calling SetProcessDefaultActCtx in a place it shouldn't, and no amount of reinstall on your end will change that. Report it to the vendor with the WinDbg stack trace. That's the only fix left.