An XML file is badly formed
A structural file will not parse at all, so nothing downstream of it can be checked.
The message you saw
An XML file is badly formed: ... (line:column)The XML in ... is malformed on line ... (...).libdcp calls this INVALID_XML. The first wording is the command-line verifier, the second is the DCP-o-matic Player. Our browser check reports the same condition as: ... is not well-formed XML.
The line number is the diagnosis
A parse failure at the very end of the file, particularly on the last element, almost always means truncation. The copy stopped early. Compare the byte length against the source and it will be short.
A failure early in the file, or on a character that looks fine on screen, points at a byte-level edit instead. A file that starts with an unexpected character often carries a UTF-8 byte order mark that a strict parser rejects.
What damages these files
Text editors are a frequent cause, because DCP XML invites hand-repair. Saving as UTF-16, adding a trailing newline inside a signature block, or letting an editor re-indent a signed document all break parsing or invalidate the signature.
Archive tools that treat XML as text will convert line endings on extraction. That is harmless for parsing but changes the file length and its SHA-1, so it usually surfaces as a hash mismatch rather than this error.
Filesystem damage rounds out the list. Structural files are small enough to sit inside a single block, so a bad sector takes out the whole document rather than corrupting part of it.
Recovery
Re-copy the file from source. These documents are a few kilobytes, so the copy is instant and it is the only fix that preserves the hash the packing list expects.
Repairing the XML by hand will make it parse and leave it failing hash verification, because the packing list records the digest of the original bytes. A file that parses but hashes wrong is a worse problem than one that does not parse, since it fails later in the chain.