Data Recovery Case File · Formatted & Logical Faults · The Right Size and Unreadable
Software Recovered the Files and None of Them Open
His enquiry described the most disheartening version of a self-attempted recovery: apparent success that turns out to be nothing of the kind. An SSD connected over USB that has failed "due to a fatal device hardware error. I have scanned it with recovery software which finds the files, but the ones that I really want are corrupted. I can save them, but they do not open." That combination looks like the data being damaged beyond help. It is not. It is a precise description of what a scanner does when it meets sectors that will not read — and understanding it explains both why the files came out unusable and why the missing pieces are very often still recoverable. The files are the right size because the software made them the right size. What it could not read, it filled in.
| Media | Solid-state drive connected externally — host reporting a fatal device hardware error; consumer scanner enumerating and saving files that will not open |
| Reported situation | Hardware-level error reported by the operating system · scan completed and files recovered · saved files structurally present but unopenable · priority material among the affected files |
| Fault class | Hardware read failures beneath a readable catalogue — recovered files padded across unreadable regions rather than genuinely reconstructed |
| Equipment used | Scanning halted · imaging under per-sector timeouts with prioritised sweep (PC-3000 Express, Data Extractor) · weak regions revisited on repeated passes · files rebuilt from recovered sectors rather than padding · every file validated by opening |
The decode: why a recovered file can be complete and unreadable
What "fatal device hardware error" establishes: the operating system is relaying something the drive reported. The system asked for data and the device returned a hardware-level failure rather than a filesystem complaint. That single word — hardware — locates the problem below the filesystem, and it is the reason everything else on this page follows.
Why the scanner found everything: the same reason described elsewhere in this archive. A filesystem's catalogue is small and stored in a concentrated area; file contents are spread across the whole medium. If the catalogue region still reads and the wider surface does not, a scanner produces a complete and accurate list of every file — an encouraging list — while being unable to fetch what the entries point at.
Why the saved files are the right size and will not open: here is the specific mechanism, and it is the part nobody explains. When a consumer recovery tool tries to read a file and hits sectors that fail, it does not usually abandon the file. It pads — writing zeros or whatever it managed to read into the gaps — and outputs a file of the correct length. The result looks perfectly healthy in a directory listing: right name, right size, right date. But a document, image or video is a structured format, and a block of padding in the middle of it is not neutral. Applications that read sequentially fail at the first bad region; formats that depend on internal offsets fail because the offsets now point at nonsense. So "I can save them but they do not open" is not a description of destroyed data. It is a description of files assembled from partial reads, with the missing parts invented.
Why the missing parts are often still recoverable: the reason this is worth doing properly. A sector that fails to read on one attempt does not necessarily fail on the next. Drives and their controllers return errors under a timeout that consumer software neither controls nor extends, and a region that defeats a single pass frequently yields to repeated, patient reads under proper timeout control — with the pass structured so that the healthy expanse is banked first, at full speed, while the device is at its strongest, and the difficult regions revisited afterwards on their own terms. Files are then rebuilt from sectors that were genuinely read rather than from padding. That is why the same files can come back openable from a managed image having come back useless from a scan.
What to stop doing: scanning. Every additional pass is spending a failing device's remaining margin on an approach that has already demonstrated what it produces. Keep the files already saved — they cost nothing to retain and occasionally one is fine — but stop generating more.
On the bench
Scanning stopped, which was the most valuable single step available. Imaging ran on the PC-3000 Express under Data Extractor with per-sector timeouts enforced and the sweep prioritised: the healthy expanse captured completely first, and the failing regions deferred to later passes where repeated patient reads recovered sectors that the consumer scan had written off in milliseconds. The filesystem was then rebuilt on the completed image and the files reconstructed from recovered sectors rather than from padding — and every one was validated by opening in the application that made it, rather than by checking that a file of the right size existed.
The outcome
The drive imaged under timeout control with weak regions re-read on later passes, and the files rebuilt from genuine data and validated by opening. Free assessment, one fixed written figure including VAT; where a drive has to be opened or a chip removed, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode, for anyone holding recovered files that will not open: they are the right size because the software made them the right size — when a scanner meets sectors it cannot read it pads the gap and writes the file out anyway, which is why the listing looks perfect and the file is unreadable; that is a description of partial reads rather than of destroyed data; and sectors that fail on one hurried attempt frequently yield to patient repeated reads under proper timeout control, so the same files can come back openable from a managed image. Stop scanning — keep what you saved, and stop making more.
Recovery software produced files that will not open
Stop scanning, and don't conclude the data is destroyed. When recovery software meets sectors it can't read, it generally doesn't abandon the file — it fills the gaps with padding and writes out something of the correct length, which is why your results have the right names, sizes and dates and still won't open. Documents, images and video are structured formats, so a block of invented data in the middle breaks them completely. That's a description of partial reads rather than lost content. The encouraging part is that a sector failing on one hurried attempt often reads successfully on a patient repeat, under timeout control that consumer software doesn't have — so the same files can come back openable when the drive is imaged properly, healthy regions first and difficult ones revisited afterwards. Keep the files you already saved just in case, unplug the drive, and stop running further scans: each one spends margin you'll want.
They were padded, not recovered — call Leeds Data Recovery on 0113 322 3083; imaged under per-sector timeouts, weak regions re-read patiently, files rebuilt from real data and opened to check.
Request a quote online →
Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.