0X000036C7

ERROR_SXS_DUPLICATE_CLSID Fix: 0X000036C7 Side-by-Side Error

The 0X000036C7 error means Windows found two side-by-side assemblies with the same CLSID. Here's how to find and remove the duplicate, plus a registry-free COM alternative.

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

  1. Open an elevated Command Prompt and run sxstrace.exe to capture the activation context:
sxstrace.exe trace -logfile:sxs.etl
  1. Reproduce the error by launching the failing application.
  2. Stop tracing and parse the log:
sxstrace.exe parse -logfile:sxs.etl -outfile:sxs.txt
  1. Open sxs.txt and look for the line that mentions ERROR_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

  1. Run the same sxstrace steps above to get the exact manifest file name and path.
  2. Navigate to the assembly folder in %WinDir%\WinSxS or the application's install directory.
  3. Look for a .manifest file that still references the old CLSID.
  4. 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.

Related Errors in Server & Cloud
0X00000431 Fix ERROR_SERVICE_EXISTS (0x00000431) in Windows Server 0X80010105 RPC_E_SERVERFAULT (0X80010105) — Server Threw an Exception Fix null VMware ESXi Can't Reach Management Network – Fixes That Work Missing Database Tables After Hosting Backup Restore

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.