SXS Manifest Missing Default Namespace Fix (0x000036C2)

Quick answer for advanced users

Open the manifest file (usually yourapp.exe.manifest), find the root <assembly> element, and add xmlns="urn:schemas-microsoft-com:asm.v1". If the manifest is embedded, use mt.exe -inputresource:yourapp.exe;#1 -out:extracted.manifest to extract, edit, then re-embed.

Why this error happens

When Windows tries to load a side-by-side assembly (SXS), it checks the manifest file for a valid XML structure. The <assembly> element must have a default namespace—think of it as a passport that says "this manifest follows the rules Microsoft set." Without it, Windows throws 0x000036C2 and the app won't start. I saw this last week on a client's legacy CRM tool—the developer's build script stripped the namespace during compilation.

Common triggers:
- You compiled an old C++ app with Visual Studio 2010 or earlier and the manifest didn't get the namespace.
- Someone hand-edited the manifest and deleted the namespace attribute.
- A third-party installer messed up the embedded manifest.

Step-by-step fix

1. Locate the manifest file. Check the app's install folder for yourapp.exe.manifest (external) or use mt.exe -inputresource:yourapp.exe;#1 -out:extracted.manifest to extract an embedded one. You'll need the Windows SDK or Visual Studio for mt.exe.
2. Open the manifest in Notepad++ or any text editor. Don't use Word or rich text editors—they add hidden characters.
3. Find the <assembly> element. It's the root tag. It should look like:

   <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

4. If the namespace is missing, add it. Change the opening tag to:

   <assembly xmlns="urn:schemas-microsoft-com:asm.v1">

   If there's already a namespace but it's wrong (e.g., xmlns:asmv1 with a colon), replace the whole thing.
5. Save the file. If the manifest was external, you're done—try running the app. If embedded, re-embed it:

   mt.exe -manifest extracted.manifest -outputresource:yourapp.exe;#1

6. Test the app. If it still fails, check the Event Viewer under Windows Logs > Application for more details.

Alternative fixes if the main one fails

Use Dependency Walker to find the real issue

Sometimes the manifest error is a red herring. Download Dependency Walker (depends.com) and open the exe. Look for red entries—missing DLLs or incorrect assembly versions trigger the same error. I had a case where a missing VC++ runtime caused this, not the manifest itself.

Reinstall Visual C++ Redistributables

If the app depends on old CRT libraries, a corrupted redist package can simulate a manifest error. Uninstall and reinstall all Visual C++ Redistributable packages (2005 through 2022) from Microsoft's site.

Use Process Monitor to trace the load

Run ProcMon, filter by the app's name, and look for "NAME NOT FOUND" or "PATH NOT FOUND" entries. This shows exactly which assembly Windows can't find. The manifest might be valid, but the target assembly is missing.

Prevention tip

If you're building apps, add a post-build step in your IDE that validates the manifest. For Visual Studio, use:

mt.exe -manifest "$(TargetPath).manifest" -validate_manifest

One more thing: never assume the manifest is the only problem. I've spent hours fixing a manifest only to find a corrupt DLL was the real cause. Always check the Event Viewer first—it's faster than guessing.