Fix ERROR_SXS_XML_E_INVALIDATROOTLEVEL (0x000036E7) Manifest Error

Cause 1: The manifest file has a stray BOM or invisible character before the root element

This is the big one. I've seen this error more times than I can count, usually after someone edits a manifest file with Notepad or a misconfigured text editor that sneaks in a Byte Order Mark (BOM) before the <assembly> tag. The XML parser sees that junk at the start and says 'nope, invalid at the top level.'

Here's the fix: open the manifest in a proper editor like Notepad++ or Visual Studio Code. Look at the very first character position — if you see anything before <assembly xmlns="urn:schemas-microsoft-com:asm.v1">, delete it. Save as UTF-8 without BOM.

If you aren't sure, run this in PowerShell against the manifest file (replace yourfile.manifest with the actual path):

Get-Content .\yourfile.manifest -Encoding Byte | Select-Object -First 3

If the first three bytes are 239 187 191, that's a UTF-8 BOM. Strip it out:

$bytes = Get-Content .\yourfile.manifest -Encoding Byte -Raw
$bytes = $bytes[3..($bytes.Length - 1)]
Set-Content .\yourfile.manifest -Encoding Byte -Value $bytes

This bit me when I was building a custom installer for a legacy app. The build script wrote the manifest with a BOM and I spent an hour cursing the Windows loader. Don't be me.

Cause 2: The manifest is malformed or has an incorrect root element

Windows side-by-side manifests expect a specific root element: <assembly> with the correct namespace. If someone renamed it, left a typo like <asmembly>, or put two root elements in there, you get 0x000036E7.

Open the manifest in a browser or an XML validator. It should start like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

No other root element allowed. No <configuration>, no <application>. The <assembly> is the root. Period.

I've also seen cases where the manifest is actually a renamed .config file. If the file has <configuration> at the top, it's not a manifest. Go get the real one from the application folder or rebuild it using mt.exe from the Windows SDK:

"C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\mt.exe" -manifest your.manifest -validate

That command will give you a line number for the error.

Cause 3: The application is loading the wrong file as a manifest

Sometimes Windows picks up a stray file with a .manifest extension that isn't a manifest at all. I saw this when a user had a leftover app.exe.manifest in the same folder as app.exe, but the file was actually a text log from an old debug session. The Windows loader found it, tried to parse it, and threw 0x000036E7.

Check the application directory for any .manifest files. If there's more than one for the same executable, that's a problem. The loader uses the one next to the EXE, then embedded resources.

Renaming the wrong one (e.g., to app.exe.manifest.bak) can fix it. But the clean move is to delete the bogus file and either embed the correct manifest using mt.exe or put the right one in the folder.

If the app is a 32-bit process on a 64-bit system, also check %windir%\SysWOW64 for redirected manifests. That's rare, but I've chased it twice.

Quick-reference summary table

If none of these work, run SxsTrace as admin: SxsTrace /trace, reproduce the error, then SxsTrace /parse the log. It'll show you exactly which file failed and why. I keep that tool on my USB stick.