Fix ERROR_XML_ENCODING_MISMATCH 0X00003714 on Windows

Had a client last month whose nightly invoice import kept dying with ERROR_XML_ENCODING_MISMATCH 0X00003714. Turns out their ERP vendor pushed an update that started writing UTF-16 files while the XML declaration still said UTF-8. Classic. The error code 0X00003714 is Windows telling you the same thing every time: the encoding written in the XML declaration (or implied BOM) doesn't match the actual byte encoding of the file. Nothing mystical — just a mismatch you can fix.

Here's how I troubleshoot it, from fastest to slowest. Stop when it works.

Step 1: The 30-Second Fix — Open, Check, Save As

Nine times out of ten, someone edited the file in Notepad, Word, or a text editor that silently rewrote the encoding. Open the XML in Notepad, look at the first line. You'll see something like:

<?xml version="1.0" encoding="UTF-8"?>

Now — and this is the part people skip — check what the file actually is. In Notepad's Save As dialog, look at the Encoding dropdown at the bottom. If it says UTF-16 LE or ANSI while your declaration says UTF-8, that's your mismatch. Change the encoding to UTF-8 (not UTF-8 with BOM if the declaration says plain UTF-8), save, and rerun whatever threw the error.

That's it. If the app loads the file now, you're done. Don't touch anything else.

Skip the online "XML validator" sites for this one. Half of them re-encode the file when you paste it in and hide the real problem.

Step 2: The 5-Minute Fix — PowerShell Byte Inspection

If Save As didn't fix it, you need to see the actual bytes. Windows will lie to you via file properties. PowerShell won't. Open an elevated PowerShell and run:

$path = "C:\Your\Path\file.xml"
$bytes = [System.IO.File]::ReadAllBytes($path)
$bytes[0..3] | ForEach-Object { '{0:X2}' -f $_ }

Now read the output:

EF BB BF — UTF-8 with BOM
FF FE — UTF-16 LE
FE FF — UTF-16 BE
3C 3F 78 6D — no BOM, raw ASCII/UTF-8 starting with <?xm

Compare that to the encoding attribute in the declaration. A BOM you didn't declare is just as bad as declaring UTF-8 on a UTF-16 file. Windows apps that use MSXML or .NET's XmlReader will throw 0X00003714 the moment they see the contradiction.

To strip a BOM while keeping UTF-8 content:

$content = [System.IO.File]::ReadAllText($path, [System.Text.Encoding]::UTF8)
$utf8NoBom = New-Object System.Text.UTF8Encoding($false)
[System.IO.File]::WriteAllText($path, $content, $utf8NoBom)

If the file is genuinely UTF-16 (say, exported by a legacy AS/400 or mainframe-based system), don't convert it — instead edit the declaration:

<?xml version="1.0" encoding="UTF-16"?>

Save it as UTF-16 LE with BOM. Done. Rerun.

Step 3: The 15-Minute Fix — Find the Real Source

If the file keeps reverting, you're fixing a symptom. Something upstream is writing it wrong. This is where most people waste an afternoon, so here's what to actually check.

3a. Scheduled tasks and batch scripts

Run schtasks /query /fo LIST /v and look for anything touching that XML. Old .bat files using echo or type to build XML will emit the console codepage, which is usually CP1252 on US Windows boxes — not UTF-8. A file that looks UTF-8 in a text editor may have raw 0x92 bytes where smart quotes live. Windows' XML parser spots that instantly.

3b. Application config

Check the app's config for an encoding setting. Common culprits:

BizTalk send/receive ports — encoding lives in the pipeline component
SQL Server bcp or BULK INSERT output — -w flag forces UTF-16
.NET middleware — look for new StreamWriter(path) with no encoding argument (defaults to UTF-8 without BOM in .NET Core, but UTF-8 with BOM in .NET Framework 4.x on some configs)

3c. Registry and system defaults (rare, but worth a look)

Some legacy COM components read from:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CodePage

If ACP is 1252 and something is emitting UTF-8 without declaring it, you'll get this error on every run. Changing the system codepage is a major undertaking — do NOT do it lightly. Better to fix the emitter.

Confirm the fix

Once you've changed the file or the emitter, validate before you re-run the app. Use .NET's own parser, since that's likely what's throwing 0X00003714 anyway:

try {
  $x = New-Object System.Xml.XmlDocument
  $x.Load("C:\Your\Path\file.xml")
  "OK: parsed clean"
} catch {
  $_.Exception.Message
}

If that prints "OK: parsed clean", the app will load it too. If it still errors, the message will tell you the exact line and byte offset — usually a stray character from a copy-paste out of Excel or Outlook. Those apps love to inject U+2019 and U+201C characters that look fine in Notepad but blow up the parser.

What NOT to do

Don't "fix" it by removing the encoding attribute. That defaults the file to UTF-8 or UTF-16 depending on BOM, and you'll hit the same error again next week.
Don't run sfc /scannow. This is not a system file problem. I've watched people burn 45 minutes on that for nothing.
Don't trust Word or WordPad. They insert XML-invalid characters and rewrite declarations without warning.
Don't convert UTF-16 to UTF-8 blindly on a file with non-ASCII characters unless you've confirmed the source bytes are actually valid Unicode. Wrong conversion embeds mojibake that looks fine until a downstream system chokes on it.

The real fix is always the same: match the declaration to the bytes, or match the bytes to the declaration, and stop whatever upstream process keeps flipping them. Once you've done that, 0X00003714 disappears and doesn't come back.