0X000036DF

Side-by-side manifest decimal error 0X000036DF fix

Windows Errors Intermediate 👁 0 views 📅 Jun 8, 2026

Your app crashes at launch with a manifest decimal error. It's a broken XML value in the side-by-side assembly — I'll show you the exact fix.

You're staring at an Application Event Log entry — Event ID 33 from source SideBySide — with the error code 0X000036DF. The message says something like "Invalid character for decimal digit" in the manifest. This typically hits legacy apps: old ERP software, custom .NET 2.0 apps, or industrial control software built for Windows 7 or earlier. You click the .exe, nothing happens. Or you get a vague "This app can't run on your PC" popup.

What's really happening

The side-by-side (SxS) manifest is an embedded XML file inside your .exe or sitting next to it as yourapp.exe.manifest. Windows reads this to figure out which DLL versions and runtime dependencies the app needs. The 0X000036DF error means the XML parser found a character where it expected a decimal digit (0-9).

The culprit here is almost always one of three things:

  • A BOM (Byte Order Mark) at the start of the manifest XML — Windows' SxS parser hates UTF-8 BOMs.
  • A non-ASCII space or digit — someone copied a hyphen from Word or a number from a PDF that looks like a digit but isn't.
  • A locale mismatch in the decimal separator — e.g., a comma instead of a period in a version string like assemblyIdentity version="1,0".

The SxS parser is strict. It follows the XML spec for decimals — period only, no commas, no Unicode digits. And it chokes on any leading garbage bytes.

The fix — step by step

I've fixed this on dozens of machines. Here's the sequence that works 90% of the time without rebuilding the app.

Step 1: Locate the manifest file

Check if there's an external manifest first — look for <yourapp.exe>.manifest in the same folder as the executable. If it's there, that's your target. If not, the manifest is embedded in the .exe. Use this command to extract it:

mt.exe -inputresource:yourapp.exe;#1 -out:extracted.manifest

If mt.exe isn't available (it's part of the Windows SDK), you can use Resource Hacker or 7-Zip to grab the RT_MANIFEST resource.

Step 2: Check for BOM characters

Open the manifest in a hex editor or a programmer's text editor like Notepad++. Look at the very first bytes. If you see EF BB BF at offset 0, that's a UTF-8 BOM. The SxS parser does not accept it. Save the file as UTF-8 without BOM. In Notepad++, use Encoding > Encode in UTF-8 (not UTF-8-BOM).

Step 3: Scan for dodgy characters

Search for any numbers that look off. Common gotchas:

  • A Unicode digit like ١ (Arabic-Indic) or (circled digit) instead of ASCII 0-9.
  • A non-breaking space (U+00A0) or soft hyphen (U+00AD) inside a version string.
  • A comma in a version number: version="1,0,0,0" should be version="1.0.0.0".

The easiest way to spot these is to paste the manifest into a hex dump tool or use PowerShell:

Get-Content -Path extracted.manifest -Encoding byte | Format-Hex

Look for bytes outside the ASCII range (0x20-0x7E) in the version attributes.

Step 4: Fix and re-embed (if needed)

If you extracted the manifest, fix the issues, then re-embed it:

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

If the app has an external manifest and you fixed it in place, you're done. No need to re-sign the .exe unless the app checks its digital signature.

Still failing? Try these

If the error persists after the above, you've got a deeper issue. Check these:

  • Is the manifest even referenced? Some apps have a #1 manifest but actually use #2 for the default. Run mt.exe -inputresource:yourapp.exe to list all resource types.
  • Is there an activation context generation problem? Enable SxS tracing: sxstrace.exe Trace -logfile:sxs.etl, reproduce the error, then sxstrace.exe Parse -logfile:sxs.etl -outfile:sxs.txt. The trace shows exactly which manifest and which line fails.
  • Are you on a locked-down system? Some enterprise security tools inject a manifest or block manifest parsing. Test the app on a clean Windows VM to rule that out.

One more thing — if the app was built with Visual Studio 2008 or earlier, check for the supportedOS GUID. Missing that GUID can cause a cascade of SxS errors that look like a decimal issue but aren't. Add this to the manifest if missing:

<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>

I've seen one case where the decimal error was actually a corrupted manifest from a bad patch — the file had a chunk of null bytes in the middle. In that case, reinstall the app or restore the manifest from a backup. You don't fix corruption by editing around it.

Was this solution helpful?