Fix ERROR_SXS_XML_E_INVALIDSWITCH 0X000036F4

You're staring at an app crash or Event ID 33, and the detail says "switch from current encoding to specified encoding not supported".

That's ERROR_SXS_XML_E_INVALIDSWITCH (0x000036F4). It's a side-by-side manifest encoding problem—not a driver issue, not a corrupt OS. The real fix is editing one manifest file. Let's do it.

The Fix: Re-encode the manifest as UTF-8 without BOM

This error happens when the manifest file starts with a UTF-8 BOM (byte order mark: EF BB BF) and then somewhere inside the XML it declares a different encoding, like encoding="utf-16". Windows can't switch mid-stream, so it throws this error.

Here's the step-by-step:

1. Press Win + R, type eventvwr, hit Enter. Look in Windows Logs > Application for a warning or error with source SideBySide. It'll tell you which manifest file failed. Write down the full path.
2. Open Notepad as administrator. (Right-click Notepad, choose Run as administrator.)
3. Go to File > Open and paste the manifest path from Event Viewer. If it's inside Program Files, you'll need admin rights to save it.
4. Once open, go to File > Save As.
5. At the bottom, click the Encoding dropdown. Change it from UTF-8 with BOM to UTF-8 (no BOM). Important: Do not pick UTF-16 or ANSI—keep UTF-8 without BOM.
6. Click Save. Overwrite the file.
7. Restart the application that was crashing.

After saving, the BOM is removed. The XML declaration inside the file can now match the actual encoding. The error goes away immediately.

Why this works: The BOM is three bytes (EF BB BF) at the beginning of a UTF-8 file. If the XML header says <?xml version="1.0" encoding="UTF-8"?>, it's fine. But if someone accidentally set the encoding to UTF-16 (or the manifest contains a <assemblyIdentity> with a different encoding attribute), Windows reads the BOM first, then hits the conflicting encoding declaration—and stops cold.

Less common variations of the same issue

You might see this error in three other situations:

1. Manifest embedded in a DLL or EXE as a resource

Some older installers embed a manifest inside the binary. You can extract it with mt.exe (part of the Windows SDK). Recompile the manifest as UTF-8 without BOM and re-embed it. That's advanced—most users don't need to go there.

2. Korzh or third-party manifest editors

Tools like Manifest Editor or Resource Hacker sometimes save manifests with a UTF-16 LE BOM but declare UTF-8 in the XML. Open the file in Notepad++, look at the encoding in the status bar. If it says UTF-16 LE BOM, convert it: Encoding > Convert to UTF-8 without BOM.

3. Corrupted manifest from a manual edit

Someone opened the manifest in WordPad or Word and saved it with a different encoding. Always use Notepad or a proper code editor (VS Code, Notepad++) to edit XML manifests.

How to prevent this from coming back

• Never save XML manifests with UTF-8 BOM. If you're writing your own manifest for a side-by-side assembly, set your editor to UTF-8 without BOM by default.
• Use sxstrace.exe to check beforehand. Run sxstrace.exe trace -logfile:sxs.etl, reproduce the error, then sxstrace.exe parse -logfile:sxs.etl -outfile:sxs.txt. The output pinpoints the exact file and line causing the switch error.
• Keep manifest files small. The longer the file, the more likely an encoding mismatch creeps in. Split huge manifests into separate assemblies if you can.
• Stick to one encoding. Don't mix UTF-8 and UTF-16 in the same app. Pick one for all your XML files and stay consistent.

One more thing: if you're using WiX or Visual Studio setup projects, check their manifest generation settings. They default to UTF-8 with BOM sometimes. Toggle it off in the project properties. That mistake catches a lot of people.

You've got the fix. The error won't come back unless someone re-saves the manifest wrong. Now go restart that application.