SXS Duplicate TLBID 0x36C9 Fix That Actually Works

You're staring at 0x000036C9 and probably wondering why Windows is being a pain over some DLL. I've fixed this exact error on everything from Server 2012 to Windows 11. It's not a hardware issue — it's a manifest screwup.

The Fix: Kill the Duplicate TLBID

The culprit here is almost always two manifests with the same tlbId attribute. That's a type library identifier. Windows Activation Context can't handle duplicates. Here's what to do.

1. Open Event Viewer (eventvwr.msc). Go to Windows Logs > Application. Look for SideBySide errors with Event ID 33 or 59. They'll point you to the exact manifest file.
2. Once you know which app or service is triggering it, find its manifest file. Common locations: C:\Program Files\[App Name], C:\Windows\System32, or inside a DLL as a resource.
3. Open the manifest in Notepad. Look for a <file> element with a tlbId. Example: <file name="some.dll" tlbId="1">. If you see two <file> entries with the same tlbId number, that's your problem.
4. Change one of the tlbId values to a unique number (e.g., 2, 3, 4). Save. Reboot the app or the service.

If the manifest is embedded in a DLL as a resource, use a tool like Resource Hacker to extract it, edit the tlbId, then recompile. Don't bother with registry edits — they rarely help here.

Example manifest snippet before fix:
<file name="helper.dll" tlbId="1" />
<file name="core.dll" tlbId="1" />  <!-- duplicate -->

After fix:
<file name="helper.dll" tlbId="1" />
<file name="core.dll" tlbId="2" />  <!-- unique now -->

Why This Works

Windows SXS (Side-by-Side) assemblies use manifests to load the right version of COM components and type libraries. Each type library needs a unique ID in the activation context. If two libraries share the same tlbId, the SXS loader throws 0x000036C9 and refuses to load the assembly. By changing one ID, the loader can distinguish them. Simple.

Less Common Variations

• Manifest in a different language: Some apps ship with localized manifests (e.g., app.exe.manifest in a en-US folder). Each language variant can trigger the same error if they share a TLBID. Check all manifest copies.
• Duplicate COM registration: Rarely, the issue isn't in a manifest but in the registry. Run regedit and search for the TLBID value (e.g., {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}). If two InprocServer32 entries point to different DLLs with the same TLBID, delete the wrong one.
• Windows Update corruption: Some updates replace system files and leave stale manifests. Run sfc /scannow then DISM /Online /Cleanup-Image /RestoreHealth. This fixed it twice on Windows 10 1909.
• Third-party security software: AVG and McAfee have been known to inject their own manifests into system folders. Uninstall them, check for leftover manifest files in System32 or SysWOW64, then reinstall a modern AV like Bitdefender.

How to Prevent This Going Forward

Stop it before it starts. Here's what I tell every team I work with.

• Use a manifest generation tool: If you're building software, let Visual Studio generate your manifests. Manual edits cause this every time. Even pros slip up.
• Version your manifests: Tag each manifest with a unique assemblyIdentity version number. That way, even if you duplicate a TLBID, the loader picks the right one.
• Test on clean systems: Dev machines accumulate all sorts of junk. Test your app on a fresh VM or a container. SXS errors show up immediately there.
• Don't disable SXS: I've seen people turn off Windows Side-by-Side Assembly via group policy. Bad idea. It breaks more than it fixes. Just fix the manifest.

That's it. 0x000036C9 is annoying but it's a one-and-done fix once you know where to look. If you're still stuck, check the Event Viewer one more time — the path to the manifest is right there in the error details.