Data Recovery Case File · Second Fixes & Trade Handoffs · Three Tools, Same Bad Data

Recovery Software Returned Only Corrupt Files

This enquiry came from an IT business acting for a domestic customer, and it reports a result that is more informative than it looks. An 8GB microSD card holding 70 audio files: "when copying files, the drive disconnected and will not read any data. Have tried three consumer recovery tools and could only recover 5 corrupt files." The instinct will be that the software was inadequate — and that is the wrong conclusion. Three independent tools producing the same poor result is not three failures; it is three consistent measurements of the same underlying problem. What the corrupt output actually proves is that the card is not returning reliable data, and that every scan was reading through a device dropping out mid-operation. This page explains why that changes the approach entirely, and why the disconnection during copying was the diagnosis all along.

The decode: what the disconnection meant, and why corrupt output is evidence

The disconnection during copying is the diagnosis: a card that drops off the host mid-transfer is not experiencing a filesystem problem. It is a device whose controller stopped responding long enough for the operating system to give up on it — an instability that appears under sustained load and is invisible during the brief interactions of everyday use. Everything that followed is explained by it.

Why three tools gave the same answer: consumer recovery software, however capable, has one structural limitation: it reads the device through the operating system, and it inherits whatever the device provides. If the card drops out mid-scan, the software receives incomplete or wrong data and has no way to know it — so it writes out files assembled from whatever it managed to read. Those files exist, have plausible sizes, and do not play, which is exactly the described result. Run a second tool and it repeats the exercise on a card that is now slightly worse; run a third and the same. The consistency is the point: three independent programs converging on five corrupt files is strong evidence that the problem lies below all of them.

What each scan cost: worth stating for the trade audience this enquiry comes from. Every full scan is a complete read of the device, and on an unstable controller that means repeated power cycling, repeated dropouts and repeated resets — each one adding wear and each one raising the chance the next attempt is worse. By the third tool, the card has been through three full passes it could not sustain. That is not a criticism of anyone; it is the natural sequence when the tools available all work the same way.

What changes with the right approach: the difference is not a better scanner but a different layer. Access is taken through hardware that sits between the card and the host and manages the instability: enforcing timeouts so a stall cannot hang the operation, absorbing resets and resuming rather than restarting, and never asking the card to mount or serve a filesystem. One image is taken that way, in a single prioritised pass. Everything afterwards happens on that stable copy — where a filesystem can be rebuilt properly, and where audio files can be validated by playing them rather than counted. If the controller fails entirely during the attempt, the chip-level route remains, reading the memory directly past it.

And the handover, credited: an IT provider who tries the reasonable options, recognises that the results are not credible, and escalates rather than presenting five corrupt files to a customer as the outcome has done the right thing by that customer. It is the same reflex this archive credits in repair shops, and it is worth saying so.

On the bench

The card's next connection was behind the DeepSpar USB Stabilizer 10Gb, write-blocked, with the inline hardware conducting a conversation the card could no longer be trusted to sustain — timeouts enforced, resets absorbed, and no mount or folder listing ever requested. A single prioritised image was taken rather than another scan, and the reconstruction ran on the copy: the filesystem rebuilt, the audio files recovered with their original names where the entries survived, and signature carving filling what the catalogue could not describe. Every file was validated by playing it rather than by size, and the set was delivered on fresh media with the chip-level route standing ready and, in the event, unneeded.

The outcome

The card imaged in one hardware-managed pass and the audio recovered, validated by playback and delivered. Free assessment, one fixed written figure including VAT; where a chip has to be removed, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode, for anyone whose recovery software returned unusable files: three tools agreeing is not three failures but one consistent finding — the device is not returning reliable data, and every program reading it through the operating system inherits that; a card that disconnected mid-copy has a controller failing under sustained load, which is the cause of everything downstream; each additional scan is a full pass on a device that cannot sustain one; and the fix is not a better scanner but hardware-managed access that enforces timeouts, absorbs dropouts and produces one stable image to work from.

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.