Fix ERROR_SXS_XML_E_RESERVEDNAMESPACE 0X000036F2

Quick answer for people who know what they're doing

Open the application manifest (usually embedded or as a .manifest file), find any namespace prefix starting with xml (like xml:foo), rename it to something else (e.g., my:foo), and re-sign or rebuild the binary.

Why you're seeing this error

Windows uses the Side-by-Side (SxS) assembly system to load DLLs and manage dependencies. Every executable or DLL has an embedded manifest or a sidecar .manifest file that declares which assembly versions it needs. The XML parser Windows uses — MSXML — follows the W3C Namespaces in XML spec. That spec reserves any prefix beginning with the characters 'x', 'm', 'l' in that order (case-insensitive). So xmlns:xml or a prefix like xml:foo is illegal. The error code 0X000036F2 maps to ERROR_SXS_XML_E_RESERVEDNAMESPACE.

What's actually happening here is the manifest was hand-written or generated by a tool that didn't sanitize the namespace prefix. I've seen this with older versions of WiX Toolset, some custom MSBuild tasks, and even manually crafted manifests for legacy COM interop. The parser rejects it before even reading the rest of the manifest — it's a hard stop.

Step-by-step fix

Identify the file. The error usually points to a specific executable or DLL in the Application event log. Look under Windows Logs > Application for source-side-by-side events with this error code. The file path is in the event details.
Extract the manifest. If it's an embedded manifest (most common), use a tool like mt.exe from the Windows SDK:
```
mt.exe -inputresource:YourApp.exe;#1 -out:extracted.manifest
```
If it's a separate file (e.g., YourApp.exe.manifest), just open it in a text editor.
Find the offending namespace declaration. Search for xmlns:xml or a prefix using xml (like xml:something). It might look like:
```
<assembly xmlns:xml="urn:something">
```
Rename the prefix. Change xml to something neutral — my, app, x — but not starting with xml. Example:
```
<assembly xmlns:app="urn:something">
```
Also update all element references: <xml:foo> becomes <app:foo>.
Re-embed the manifest (if it was embedded). Using mt.exe again:
```
mt.exe -manifest fixed.manifest -outputresource:YourApp.exe;#1
```
If the binary is signed, you'll need to re-sign it after this step. Windows won't load a modified signed binary without a valid signature.
Test the application. Run it. If the error is gone, you're good. If not, double-check you didn't miss another xml-prefixed namespace. Some manifests have multiple declarations.

If the main fix doesn't work

Sometimes the manifest is correct, but the manifest generator is the culprit. Here's what to try:

Edit the source code. If you're using Visual Studio, check the project properties > Linker > Manifest File. Set Generate Manifest to No, then write a static manifest file manually and include it as a resource. This gives you full control over the namespaces.
Use a different XML serializer. If your toolchain is generating the manifest, switch to a newer version. WiX 3.14+ fixed this issue. Older WiX versions sometimes used an incorrect namespace prefix for the assembly identity.
Disable SxS fallback (temporary workaround). Set the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\PreferExternalManifest to 1 and place a correctly-written external manifest. This doesn't fix the root cause but can unblock testing.
Check for third-party obfuscation. Some packers and obfuscators embed manifests with reserved prefixes. Contact the vendor for an update, or unpack and re-manifest the binary.

Prevention tips

This is 100% avoidable with a few habits:

Never write namespace prefixes by hand — let the XML library handle it. If you must, remember xml (case-insensitive) is the only reserved prefix in XML 1.0.
Use a schema-aware XML editor that flags reserved namespace prefixes.
Pin your build tools: WiX, MT.exe, and MSBuild versions. Updating them blindly can break manifests, but staying too old (pre-2019) risks this exact bug.
Add a build step that validates the manifest with mt.exe -validate_manifest -manifest yourapp.exe.manifest. This catches reserved namespaces before the app ships.

Real-world trigger: This error commonly appears after upgrading a Windows 10 1809 application to Windows 11 22H2. The older manifest had xmlns:xml="urn:schemas-microsoft-com:asm.v3" which worked on older MSXML6 but got stricter in 22H2. Updating the prefix to asmv3:xmlns="urn:schemas-microsoft-com:asm.v3" and rewriting all references fixed it.