What does Windows error code 14100 (ERROR_XML_ENCODING_MISMATCH) mean?

Status / error code:		Category:

Constant name:
Source:		Operating System:
Description: The character encoding in the XML declaration did not match the encoding used in the document.

Previous	Next
ERROR_ADVANCED_INSTALLER_FAILED	ERROR_SXS_MANIFEST_IDENTITY_SAME_BUT_CONTENTS_DIFFERENT

ERROR_XML_ENCODING_MISMATCH

The character encoding in the XML declaration did not match the encoding used in the document.

ERROR_XML_ENCODING_MISMATCH is Windows status 14100 (0x00003714) associated with an XML document whose declaration disagrees with the actual byte encoding. The system meaning is “this condition” Preserve the value at the API boundary because subsequent cleanup or logging calls can overwrite the last-error state.

Operational meaning

The key question is whether the XML declaration, byte-order mark, transport metadata, and decoded bytes identify the same encoding. The value describes an XML document whose declaration disagrees with the actual byte encoding; it does not prove that the whole domain, DNS service, network, servicing stack, application package, or operating system has failed.

Likely impact: Different parsers may decode the mismatch differently, so accepting it can make package behavior nondeterministic. Record the scope that was actually tested instead of escalating from one rejected object or phase to a system-wide outage.

Where the result appears

This result can appear while processing an XML document whose declaration disagrees with the actual byte encoding.
This result can appear while component installation, package servicing, manifest processing, or resource substitution.
This result can appear while a setup engine invoking an advanced, primitive, or generic installer step.
It can appear while XML or localized-content parsing before a component can be committed.

Typical causes

the file declares UTF-8 but contains UTF-16 bytes.
a BOM conflicts with the declaration.
text was transcoded without updating the declaration.
a tool writes locale bytes into a fixed declaration.

Diagnostic sequence

capture it immediately after the failing or status-returning call and record whether the API uses Win32, DNS_STATUS, HRESULT conversion, or callback semantics.
identify the exact target involved in an XML document whose declaration disagrees with the actual byte encoding, including stable GUIDs, DNs, zone names, package identities, file hashes, policy names, or process identifiers as applicable.
prove the state boundary: the XML declaration, byte-order mark, transport metadata, and decoded bytes identify the same encoding.
collect raw leading bytes and BOM and XML declaration before restarting services, deleting objects, rebuilding packages, or changing policy.
correlate HTTP or file metadata with CBS.log, setup logs, servicing stack events, installer stdout/stderr, manifest identity, XML bytes, and the first HRESULT or process exit code.
determine whether the result is a failure, warning, informational completion, continuation request, or marker constant before choosing retry behavior.
after changing one responsible condition, repeat the same smallest operation and verify both success and absence of unintended partial effects.

Evidence to preserve

collect raw leading bytes and BOM.
collect XML declaration.
collect HTTP or file metadata.
collect producer and transcode step.
collect parser line and byte offset.

Preserve raw identifiers and the first detailed diagnostic: translating everything to 14100 can hide whether the cause was validation, topology, authorization, replication, policy, file I/O, packaging, or an intentional continuation state.

Recovery and retry

The recovery objective for it is to regenerate the XML from one authoritative Unicode representation with matching declaration and bytes; do not patch only the displayed text.

Retry only after the recorded boundary changes and prior completion is known. Read-only discovery for it can usually be repeated with bounded backoff; directory mutations, DNS updates, policy installation, servicing actions, and PRI writes require a state check first. Backoff for it cannot repair malformed input, unsupported structure, identity collision, missing authority, or incompatible package metadata.

Telemetry and support fields

record xml_encoding_mismatch_operation — producing API, command, callback, or servicing phase.
record xml_encoding_mismatch_target — stable object, zone, policy, package, file, or account identity.
record xml_encoding_mismatch_state_before and xml_encoding_mismatch_requested_state.
record xml_encoding_mismatch_first_status — earliest component-specific code before translation.
record xml_encoding_mismatch_server, xml_encoding_mismatch_process, UTC timestamp, and correlation ID.

A support bundle for it should include decimal 14100, hexadecimal 0x00003714, the smallest reproducible request, target identity, effective configuration, and evidence from the owning Windows component. When documenting it, remove secrets from exported logs but keep SIDs, GUIDs, package-family names, record types, and hashes when they are needed to distinguish objects.

Difference from nearby results

ERROR_XML_PARSE_ERROR is a general syntax failure; this code specifically identifies encoding disagreement This distinction determines whether the correct next step is input correction, topology repair, continuation, policy review, package rebuild, or no error handling at all.

Practical validation scenario

A servicing manifest declares UTF-8 but was saved as UTF-16LE. Re-exporting it with matching declaration and bytes allows parsing. A negative test should reproduce it with the responsible condition preserved; the recovery test should alter only that condition and confirm the intended final state.

Developer and administrator guidance

Developers should model it explicitly in the result domain instead of collapsing every nonzero value into “failed.” Administrators should capture evidence before destructive remediation and use the component that owns an XML document whose declaration disagrees with the actual byte encoding. Monitoring for it should suppress range markers and classify warning, informational, cancellation, and continuation values separately from terminal failures.

References

Microsoft: exact Win32 system error range — official context relevant to it.
Microsoft: Assembly manifests — official context relevant to it.
Microsoft: Side-by-side assemblies — official context relevant to it.

Looking for a different code? Search another status or error code.