Fix ERROR_SXS_XML_E_UNEXPECTED_STANDALONE (0x000036F7)

Quick answer for advanced users

Open the application's .manifest file or the embedded manifest inside the .exe using a resource editor. Find the <?xml version="1.0" standalone="yes"?> declaration inside a file that is not the top-level XML — likely a referenced or included manifest file. Delete the standalone attribute entirely. Recompile or repackage the app.

Why this happens

Windows uses side-by-side (SxS) manifests to tell an application which versions of DLLs it needs. When you get error 0x000036F7, Windows is saying: "I found a standalone attribute in an XML declaration, but it's not at the top of the document tree." The XML spec is strict — standalone can only appear in the XML declaration of the outermost file. If you have a manifest that includes or references another XML file (like an assembly manifest), and that inner file has standalone, Windows rejects the whole thing.

This error usually shows up when you install a third-party application, especially older ones or custom in-house tools that were built with a buggy manifest generator. You might see a message like "The application has failed to start because its side-by-side configuration is incorrect." Event Viewer logs the same error under Application Events with source SideBySide.

I've seen this a lot with apps that were compiled using old versions of Visual Studio or with custom manifest tools that blindly copy the same XML header into every file. The fix is straightforward once you know where to look.

Fix steps

Before you start, you need to know which file is causing the error. The error message doesn't always tell you the filename, but Windows gives you clues in Event Viewer. Let's start there.

1. Open Event Viewer. Press Win + R, type eventvwr.msc, and hit Enter. Go to Windows Logs > Application.
2. Find the SideBySide error. Look for events with Source "SideBySide" and Event ID 33 or 35. Double-click the most recent one. The event details usually include the manifest file path. Write it down. Example: C:\Program Files\SomeApp\app.exe.manifest or C:\Windows\WinSxS\Manifests\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_*.manifest.
3. Open the manifest file in a text editor. Use Notepad++ or VS Code. Do not use Notepad — it doesn't show line numbers well. If the file is inside the .exe itself (common for single-file apps), you need a resource editor like Resource Hacker.
4. Search for standalone. Press Ctrl+F and type standalone. You're looking for something like <?xml version="1.0" standalone="yes"?> or standalone="no".
5. Check if it's the top-level file. If the manifest file you opened is a referenced assembly (like a CRT manifest or a policy manifest), the standalone attribute is illegal there. Delete the entire standalone attribute from the XML declaration. The declaration should become <?xml version="1.0"?>.
6. Save the file. If you modified a resource-inside-an-exe, recompile the resource file and rebuild the app. If you modified a standalone .manifest file in the app folder, save it in place.
7. Test the app. Launch the application. If it still fails, restart the app or reboot — Windows caches some manifest data.

Alternative fixes if the main one fails

Sometimes the manifest file is signed or protected by Windows Resource Protection (WRP). You can't edit files in C:\Windows\WinSxS\ directly. In that case, you have other options.

• Use a manifest redirect. Create a new .manifest file alongside the .exe with the correct XML declaration, then use mt.exe (the Manifest Tool from the Windows SDK) to embed it. Run: mt.exe -manifest app.exe.manifest -outputresource:app.exe;1. This replaces the embedded manifest.
• Disable SxS for that specific app. Not ideal, but if the app works without the manifest, you can delete or rename the .manifest file. The app will run in compatibility mode. This works for simple apps that don't depend on specific DLL versions.
• Reinstall the app with a newer version. If the app is a known product (like an old Adobe tool or a custom utility), check for a patch. Many vendors fixed this after Windows 10's stricter XML parsing.
• Use Process Monitor to find the exact file. Run ProcMon, filter by Process Name = your app's .exe, and look for CreateFile operations with .manifest in the path. The one that returns NAME NOT FOUND or FILE LOCKED is the culprit.

Prevention tip

If you're a developer or maintainer building apps, never put a standalone attribute in any manifest file that isn't the main entry point. The standalone attribute is almost always unnecessary — it tells parsers whether the XML file depends on external DTDs. In practice, Windows ignores it for top-level manifests and rejects it for others. Just leave it out altogether. Write your XML declarations as <?xml version="1.0" encoding="UTF-8"?> and stop there. Also, use a schema validator on your manifests before shipping. The Windows SDK includes sxsapi.dll functions that let you test manifests programmatically, or you can use the mt.exe -validate command.