Cause 1: Duplicate CLSID Across Two SxS Assemblies
What's actually happening here is that Windows is loading a side-by-side (SxS) assembly and finds two different assemblies claiming the same COM class ID. The SxS activation context can't decide which one wins, so it throws ERROR_SXS_DUPLICATE_CLSID (0X000036C7). You'll usually see this when launching an application that uses a shared COM component, like a printer driver, a shell extension, or an installer.
The most common trigger: you installed two versions of the same runtime or component that both register the same CLSID without a version-dependent ProgID. I've seen this with older VC++ redistributables and some printer vendor utilities.
Fix: Identify and Remove the Duplicate Assembly
- Open an elevated Command Prompt and run
sxstrace.exeto capture the activation context:
sxstrace.exe trace -logfile:sxs.etl
- Reproduce the error by launching the failing application.
- Stop tracing and parse the log:
sxstrace.exe parse -logfile:sxs.etl -outfile:sxs.txt
- Open
sxs.txtand look for the line that mentionsERROR_SXS_DUPLICATE_CLSID. It will name the two assemblies and the offending CLSID.
Once you know the assembly names, check the %WinDir%\WinSxS folder for the two versions. The fix is to uninstall the one that's not needed. If it's a patched version, keep the newer. If it's an old standalone component that's been superseded, remove it via Programs and Features or dism for Windows components.
For example, if the duplicate involves a VC++ redistributable, uninstall both versions and reinstall the latest from Microsoft. That often clears the collision because the newer package includes a proper side-by-side manifest.
Cause 2: Incomplete or Corrupted Manifest Entry
Another frequent cause is a broken manifest file that lists the same CLSID twice, or lists a CLSID that's already in use by a different assembly. This happens after a partial uninstall or when a software update overwrites a manifest but leaves the old one behind.
You'll see this if you recently removed an application and something else still tries to use its COM class. The activation context can't resolve the duplicate.
Fix: Clean Up the Corrupted Manifest
- Run the same
sxstracesteps above to get the exact manifest file name and path. - Navigate to the assembly folder in
%WinDir%\WinSxSor the application's install directory. - Look for a
.manifestfile that still references the old CLSID. - If the file is no longer used by any installed program, delete it and rebuild the component catalog with:
sfc /scannow
But wait — sfc /scannow only fixes protected system files. If the manifest belongs to a third-party app, you'll need to reinstall that app to get a clean manifest.
The reason step 4 works: sfc checks the component store against known good copies and repairs any mismatched or missing manifests. If the duplicate is in a system assembly, this clears it.
Cause 3: Registry-Free COM Registration Conflict
Sometimes the CLSID isn't in a physical registry entry but is declared in the SxS manifest via <comClass> entries. If two assemblies on the same machine both declare the same <comClass clsid="...">, you get the duplicate error even if the registry is clean.
This is common with applications that bundle their own runtime or with plugins that share a common dependency but each carry their own manifest.
Fix: Force a Single COM Class Implementation
The cleanest fix is to change one of the assemblies to use a different CLSID. You can't edit the manifest of a signed assembly without breaking its hash, so if you control the source, recompile with a unique GUID. If you don't control the source, you need to isolate the two apps so they don't share an activation context. Run one of them in a separate session or use a compatibility shim.
A practical workaround: use regsvr32 to manually register the COM class that the failing app expects, then remove the SxS declaration from the app's manifest if it's a plain text file. But be careful — if the app's manifest is embedded in the EXE, you'll need a resource editor to strip it.
Quick-Reference Summary
| Cause | Diagnosis | Fix |
|---|---|---|
| Duplicate CLSID across two SxS assemblies | sxstrace shows two assembly names with same CLSID |
Uninstall the redundant component or reinstall latest version |
| Corrupted or leftover manifest | Manifest file references a CLSID used elsewhere | Delete orphaned manifest and run sfc /scannow or reinstall the app |
| Registry-free COM conflicts | Multiple <comClass> entries with same GUID |
Recompile with unique GUID, or register via regsvr32 and bypass manifest |
If you're still stuck, the nuclear option is to boot into safe mode and run dism /online /cleanup-image /restorehealth to refresh the component store. It's slow but it often resolves stubborn SxS corruption. Don't skip the sxstrace step though — that log tells you exactly which CLSID is conflicting, and that's half the battle.