Separate representation problems from game semantics
A fail-closed Dreamcast VMU / VMS Save Formats 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: Dreamcast Visual Memory Unit flash images and the specifically documented Nexus DCM and VMI metadata representations. SaveEditor treats fixed filesystem/root constants as evidence only and does not synthesize CRCs, FAT chains, directory entries, allocation state, or game payload bytes.
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: Dreamcast DCM Byte Order Inspector, Dreamcast DCM Directory Inventory, Dreamcast DCM Directory Location Recovery, Dreamcast DCM FAT Location Recovery, Dreamcast DCM Filesystem Consistency Auditor, Dreamcast DCM Root Marker Recovery, Dreamcast DCM VMU Layout Inspector, Dreamcast Nexus DCM Fingerprint and 23 additional verified Tool(s). 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.