Data Recovery Case File · Solid State & Flash · The Trouble That Started Months Before
USB Stick Died After Months of Warnings
His enquiry contained a timeline, and the timeline is the lesson. A SanDisk 128GB USB stick holding the photographs from a timelapse shoot: "unfortunately the stick appears to have died. I saw it start to give trouble back in August." It will no longer connect to any Mac or Windows computer. And the question he actually wants answered: "what are the chances of this being recovered with all images saved?" Two things owed to him. First, what those months of trouble were — because flash storage does give warnings, they are consistently misread as inconvenience rather than as failure in progress, and knowing what they mean is worth more than any recovery. Second, an honest answer to the word all, which is the part most firms would rather leave vague.
| Media | SanDisk 128GB USB flash drive holding a timelapse photographic sequence — intermittent problems over several months, now unrecognised by any host |
| Reported situation | Early warning signs observed and worked around · progressive deterioration to total failure · no connection achievable on Mac or Windows · owner asking for realistic completeness of recovery |
| Fault class | Progressive flash failure ending in non-enumeration — controller failure over NAND with accumulated wear; chip-level access with per-block integrity variation |
| Equipment used | PC-3000 Flash with Spider Board chip-level reads · Rusolut VNR pinout and reconstruction — XOR, ECC correction and translation rebuild · sequential JPEG carving with per-frame validation · completeness reported against the sequence rather than asserted |
The decode: what the warnings were, and an honest answer about "all"
What months of trouble actually meant: flash storage rarely dies without notice — it is simply that the notice does not look like a warning. Transfers that slow to a crawl, a copy that stalls near the end, files that will not open one day and open the next, the stick disappearing mid-transfer and reappearing when reinserted, a computer that hangs while reading it. Every one of those is the controller struggling: retrying failing blocks, exhausting spare capacity, taking longer and longer to complete operations it used to do instantly. People work around them because working around them succeeds — until the day it does not. His "I saw it start to give trouble" is the single most valuable sentence in the enquiry, because it dates the failure's beginning to months before it finished, and it is the thing this page most wants readers to recognise in their own storage.
Why the odds are still reasonable: a stick that has stopped enumerating has a controller that no longer conducts the introduction, and the NAND behind it is read directly at chip level, bypassing the controller entirely. That much is routine. What the months of warnings change is the condition of the memory: a device that struggled for a long time has accumulated worn blocks and correction failures, so the raw dump will contain regions that read cleanly and regions that do not.
The honest answer to "all": nobody can promise that word before reading the device, and it is worth being clear about why. Chip-level recovery from a worn device typically returns the great majority of the data with some blocks unrecoverable, and where those blocks fall determines what is lost. Here his subject matter helps considerably. A timelapse sequence is thousands of sequential still images, each one small, self-contained and carrying a strong internal signature — which is close to the ideal case for content-based recovery. Damage that would ruin a single large file tends, in a sequence like this, to cost individual frames rather than the sequence. And a timelapse missing a handful of frames out of thousands is often still usable, because the gaps are momentary. So the realistic expectation is: most of it, very likely nearly all of it, with any losses identified frame by frame rather than estimated — and stated as a count against the sequence rather than described as a success.
On the bench
The stick was read at chip level from the outset, since its refusal to enumerate on any host had already settled that question. The memory was probed on the PC-3000 Flash Spider Board with the pinout confirmed against the Rusolut VNR database, and the raw dump was taken with per-block error correction applied as aggressively as the ECC scheme allowed — the stage where months of accumulated wear shows itself, and where patience returns blocks that a first pass rejects. Reconstruction ran XOR descrambling and translation rebuild to stand the filesystem back up, and the timelapse sequence was carved with per-frame validation: every image rendered and checked rather than counted. The recovered set was delivered in shooting order with the missing frames listed explicitly by position, so he could see exactly what he had.
The outcome
The sequence recovered at chip level and validated frame by frame, with losses reported by position rather than glossed. 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. Two things to take from his timeline: flash does warn you, but the warnings look like inconvenience — slow transfers, stalled copies, files that open intermittently, a stick that vanishes mid-copy — and every one of them means the controller is struggling and the device should be emptied that day; and on the question of recovering all of it, expect an honest count rather than a promise, and take comfort that sequences of small self-contained images are among the most forgiving material there is.
Storage that has been misbehaving for months
Treat the misbehaviour as the warning it is and act while the device still works. Slow transfers, copies that stall near the end, files that open one day and not the next, a stick that disappears mid-copy, a computer that hangs while reading it — these are not quirks to work around, they're a controller retrying failing blocks and running out of spare capacity. The right response is to copy everything off that day and retire the device, because the window closes without further notice. If it has already stopped enumerating, don't keep plugging it into more machines: the memory behind a dead controller is read directly at chip level, and further attempts add nothing. When you ask about completeness, expect an honest answer — a worn device usually gives up most of its contents with some blocks unrecoverable, and you should be told which files are affected rather than given a percentage.
The memory is still readable — call Leeds Data Recovery on 0113 322 3083; read at chip level, corrected block by block, every frame validated and any losses listed by position.
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.