Separate representation problems from game semantics
A fail-closed XML Save Files troubleshooting guide for distinguishing representation problems from unsupported semantics and for selecting read-only integrity checks before any repair attempt. The existing format hub describes the representation as: XML-based save and configuration data with explicit text structure. XML validity is separate from game-specific field meaning or integrity rules.
Start by asking whether the failure is at the representation layer or inside game-specific data. Representation checks can establish framing, parseability, fixed markers, checksums, redundant metadata, allocation structure, or wrapper relationships only when an existing verified parser implements those checks. They do not automatically explain unknown inventory, progression, account, encryption, or title-specific fields.
Use read-only evidence before repair
Existing verified Tool context includes: XML Editor, XML Formatter. Use read-only inspectors, fingerprints, forensic reports, or validators first when available. A Tool listed for the format can still have a purpose narrower than the format as a whole, so its individual support and refusal rules remain authoritative.
Record the source size and SHA-256 where practical, then work from a copy. Compare structural reports before and after any authorized change. If a wrapper contains an embedded save, distinguish wrapper damage from payload damage. If a card image contains filesystem metadata, distinguish directory or allocation problems from bytes inside an individual game save.
Fail closed when the correct bytes are unknown
A failed checksum does not automatically reveal the correct replacement bytes. A broken directory does not prove which allocation chain should win. Two valid redundant copies may still be ambiguous if neither has an independently established precedence rule. Likewise, encryption or digital signatures cannot be regenerated merely because the outer structure can be parsed.
Do not synthesize missing payload bytes, rewrite unknown metadata, select a newer or better save from timestamps alone, or promote a file because its extension and size look plausible. Use repair, migration, conversion, signing, decryption, or editing only when an existing verified Tool explicitly owns that exact operation and its prerequisites are satisfied.
Verify any authorized output
After an authorized repair or edit, compare the output against the original and verify that only the documented byte scope changed. Reopen the result through the strict parser, re-run the relevant checksum or structural checks, and retain the original backup. A successful download alone is not proof that the target game or emulator will accept the result.
If multiple defects remain, if the result cannot reopen, if integrity checks disagree, or if the format requires account-bound signing or other unsupported protection, stop at diagnosis. Preserve the evidence report and source copy rather than escalating to a broader mutation that the verified Tool contract does not authorize.