Guides / Corrupted after USB or data recovery
The Excel file came back from data recovery, and now it won't open
Updated August 29, 2026
The pattern is always the same: a deleted file, a formatted card, a USB stick that started throwing errors, a chkdsk run that “fixed” the drive. A recovery tool (Recuva, PhotoRec, Disk Drill, TestDisk, whatever the forum recommended) triumphantly brings the spreadsheet back. And Excel refuses it. This guide explains why that happens and, more usefully, what's actually realistic to save.
Why recovered files come back broken
Deleting a file doesn't erase its data. It deletes the index entry that says where the pieces live, and marks that space reusable. A recovery tool works by guessing the layout back: it finds the old index entry (or recognizes the file's opening bytes) and reads where the pieces used to be.
The guess fails in predictable ways:
- Fragmentation. If the file wasn't stored in one continuous run, the tool often grabs the true first chunk and then whatever now occupies the following clusters: another file's bytes wearing your file's name.
- Partial overwrite. Space freed by deletion gets reused. Every minute the drive stayed in service, more of your file's old bytes were replaced.
- Truncation. Dying flash drives and interrupted copies simply stop early. The front of the file is real, the tail is missing or zero-filled.
Here's why that's so lethal for Excel specifically: an .xlsx is a ZIP archive, and ZIP puts its table of contents (the central directory and the end-of-central-directory record) at the very end of the file. A recovered file missing its tail is missing precisely the structure Excel demands before it will read anything. The worksheet data earlier in the file may be perfectly intact; Excel never gets far enough to look.
Before repairing anything: look for a better copy
A repair of a mangled recovery is the last resort, not the first move. Cheaper wins, in order:
- Stop writing to the affected drive now. Every write can overwrite the bytes you're trying to save. Recover to a different drive, always.
- Re-run recovery, differently. Try a second tool or your tool's deep/signature-scan mode; different heuristics find different copies. PhotoRec-style signature scanning sometimes finds an older, intact autosaved copy of the same workbook under a meaningless name.
- Check every other place the file has been. OneDrive/Drive/Dropbox sync copies and their version history, email attachments (sent and received), Excel's own AutoRecover folder (File → Info → Manage Workbook → Recover Unsaved Workbooks), backups, the coworker you once shared it with. An intact older version beats a repaired fragment every time.
- If chkdsk ran: raid the FOUND.000 folder. Files named FILE0001.CHK are rescued fragments. Copy them elsewhere, rename copies to .xlsx, and test. A text editor showing PK as the first two characters marks a ZIP-based candidate.
- Then try the standard openers on a copy. Excel's Open and Repair (File → Open → Browse → single-click the file → arrow next to Open), then LibreOffice Calc, which tolerates more damage. Fair warning: on truncated archives both usually fail. They still want that table of contents at the end. Details in the extension-not-valid guide.
Built for exactly this failure
Truncated archives are the case FileQuiet's repair was designed around. It doesn't need the ZIP table of contents at all: it scans the raw bytes for each entry's local PK header, reconstructs the archive from those, tolerates a cut-off final entry, decompresses leniently, and salvages worksheet rows up to wherever the data really ends. If the real front of your spreadsheet came back, it can usually show you what's in it.
The scan runs in your browser; the file is never uploaded, which the network tab will confirm. The free preview shows the actual recovered tabs and rows. If the recovery brought back someone else's bytes and nothing of yours survives, the preview shows nothing and there's no pay button. $12 one-time when there is something worth downloading.
Scan the recovered file, freeHonest limits: we salvage what physically survived. Rows past the truncation point are gone; formulas return as last-known values; formatting is mostly lost; encrypted workbooks are out of scope.
Frequently asked
Why won't my Excel file open after I recovered it with an undelete tool?
Deleting a file removes its index entry, not its data. The space becomes reusable. A recovery tool guesses where the file's pieces were; on a fragmented or partly reused drive, the guess brings back the real start of your file with someone else's bytes, zeros, or nothing at the end. Since an .xlsx keeps its ZIP table of contents at the very end of the file, that's exactly the part most often missing, so Excel refuses the file.
Can .CHK files from chkdsk be turned back into Excel files?
Often. When chkdsk sweeps up orphaned data it saves the fragments as FILE0001.CHK and so on, in a FOUND.000 folder. Some of those are complete files with the wrong name: copy one, rename the copy to .xlsx, and try opening it. If a text editor shows the copy starting with PK, it's a ZIP-based file and a strong candidate. Partial fragments need a salvage tool that can rebuild an incomplete archive.
Is it worth running data recovery again before trying to repair the file?
Usually yes, if the drive hasn't been written to since. A different tool, or the same tool's deep-scan mode, can find a better copy of the same file. Stop using the affected drive immediately (every write risks overwriting your data), recover to a different drive, and try more than one tool before settling for a damaged copy.
Can trying repairs make the file worse?
Not if you work on copies. Reading a file doesn't change it, and every repair should output a new file. Two real risks to avoid: saving anything (including repaired output) back onto the drive you're recovering from, and letting a repair tool overwrite your only copy in place. Keep the original untouched, work from duplicates, and save results to a different drive.