Fix 0X000036ED Manifest Unclosed End Tag Error

You double-click your app and nothing happens. Or you get a dialog boxing saying "The application has failed to start because its side-by-side configuration is incorrect." You pull up Event Viewer and see ERROR_SXS_XML_E_UNCLOSEDENDTAG with code 0X000036ED. That's the tell. Something in one of your manifest XML files has an opening tag that never got its closing > character. The Windows side-by-side (SxS) loader tried to parse it, hit end of file, and gave up.

When this error actually shows up

The classic trigger is a developer or build engineer hand-editing a manifest. Someone opens app.manifest or an .exe.manifest in Notepad, adds a new <assemblyIdentity> or <dependency> block, and forgets the trailing >. Save. Build. Ship. It runs fine on their machine because the manifest is cached, then blows up on every fresh install.

I've also seen it after a bad merge in Git. Two devs edit the same manifest, the merge tool combines the lines, and the closing bracket ends up on a line by itself with a stray space. XML doesn't care that it looks close — it cares that > is the exact next character.

One more real-world case: an installer script that writes a manifest with a string template. A missing > in the template means every generated manifest is broken. You'll only catch it when a clean machine runs the app.

What the error actually means

XML has strict rules. Every tag must open with <name" and close with >. When the parser reaches end-of-file while still inside a tag, it throws XML_E_UNCLOSEDENDTAG. That maps to Windows error 0x36ED.

The name is a little misleading. "End element was missing the angle bracket" doesn't mean </foo> is missing. It means the parser finished reading a tag's content but never saw the closing > before the file ended or before the next < appeared. So both of these trigger it:

<assemblyIdentity name="MyApp" version="1.0.0.0"

Here the tag never closes at all. Or:

<dependency>
  <dependentAssembly>
    <assemblyIdentity name="foo" version="1.0.0.0" processorArchitecture="x86"
  </dependentAssembly>
</dependency>

The <assemblyIdentity> line is missing its >, so the parser sees </dependentAssembly> next and panics. That second pattern is the one that bites people because it looks fine when you skim it.

The fix

The hard part isn't fixing the file. It's finding which file. SxS loads manifests from several places, and Windows won't tell you which one failed in the Event Log by default. Here's how to pin it down.

Reproduce with sxstrace running. Open an elevated Command Prompt. Run:
```
sxstrace.exe Trace -logfile:sxs.etl
```
You'll see "Tracing started. Trace will be saved to file sxs.etl." Now launch the failing app. Wait for the error. Go back to the prompt and press Enter to stop the trace. You should see "Tracing stopped."
Convert the trace to readable text. Run:
```
sxstrace.exe Parse -logfile:sxs.etl -outfile:sxs.txt
```
Open sxs.txt in Notepad. Search for ERROR_SXS_XML_E_UNCLOSEDENDTAG or just 0x36ED. A few lines above that, you'll see the full path to the manifest that failed. Something like C:\Program Files\Contoso\bin\Contoso.exe.manifest.
Open the manifest in an editor that shows line numbers. Notepad++ is fine. Visual Studio Code is better because it highlights XML syntax errors live. Paste the file in. If you see a red squiggle at the top of a tag, that's your culprit.
Validate the XML. If you have Visual Studio installed, use mt.exe to validate:
```
mt.exe -manifest Contoso.exe.manifest -validate_manifest
```
You'll get a specific line and column. That's the fastest path. If you don't have mt.exe, open the file in any browser — Chrome and Edge both parse XML and will show you the offending line number when parsing fails.
Fix the missing >. Look for a line that ends inside a tag. Add the closing bracket. Save as UTF-8 without BOM. A BOM at the top of a manifest is another classic SxS complaint, but it's a different error code.
Rebuild if it's embedded. Manifests can be embedded resources inside the .exe. If sxstrace points to an internal manifest rather than an external file, you need to rebuild the app with the corrected source manifest. You can't edit the embedded one in place without tools.
Test on a clean machine. Clear the SxS cache if you want to force a re-read on the current box:
```
net stop sxssrv
rd /s /q %windir%\WinSxS\ManifestCache
net start sxssrv
```
On Windows 10 and 11 the SxS service is a kernel driver, not a normal service, so net stop won't work. Reboot instead. That flushes the cache reliably. The real fix is always the file, not the cache — don't get sidetracked clearing caches as a first step.

If it still fails after rebuilding

Three things to check, in order.

One: encoding. Manifest files must be UTF-8 or UTF-16. If your editor saved as UTF-8 with BOM, the SxS loader sometimes chokes. Re-save as plain UTF-8. In Notepad++ that's Encoding > UTF-8 (not "UTF-8-BOM"). In VS Code click the encoding in the status bar, then Save with Encoding > UTF-8.

Two: the manifest is coming from a DLL, not the EXE. SxS loads dependency manifests too. Re-run sxstrace and look for the second or third manifest in the log. Fix them all. One broken manifest can mask another.

Three: your build system is regenerating the broken file. If you edit the manifest on disk but a pre-build step overwrites it, you'll fix it and it'll come back. Grep your CI pipeline for the manifest path. Check for template files (*.manifest.template) that might contain the same bug.

One thing that trips people up: this error code looks scary in Event Viewer, but it's almost never a Windows problem. It's a file problem. Fix the file, and Windows is happy again.

If you're still stuck, post the relevant chunk of the manifest from sxs.txt — the lines just above the error — and the failing tool will usually jump out immediately. Nine times out of ten it's a missing > on a line someone edited at 11pm before a release.