Flash and SSD · case file · CDF-2025-0918
First It Refused Saves, Then It Refused Everything.
One stick held the lot for an Ebbw Vale history group: parish registers photographed page by page, wartime magazines, and the memories of older residents typed up over a run of winters. It went downhill in a particular order. In March the library's computer would not accept anything new
; by June the folders had stopped opening; now the only response left is USB device not recognized
.
Does that match yours? Call us.
0800 6890668
Why that happens.
The order of the symptoms is the whole story here. Flash wears out when you write to it, not when you read it: every program-and-erase cycle takes a little life out of a cell, while reading takes none at all. So saves failing in March and access failing in June is the ordinary shape of a worn-out stick. While there are spare blocks left in reserve, the controller retires the tired ones quietly and keeps its own translation tables on cells it still trusts. When the reserve runs dry, those tables go with it, and the stick stops answering the bus. Windows is telling you about a silent controller, not about the scans.
What we used on this one.
Every step, in order →| The tools | What it did here | Why it helps |
|---|---|---|
| PC-3000 Flash | Identified the NAND from its library, then read it off the board | Bypasses the controller to read the NAND itself, against a manufacturer-ID library kept up to date |
| Rusolut Visual NAND Reconstructor | Removed the XOR mask and put the pages back into the order the dead controller had used | Turns a raw NAND dump into something readable: ECC, XOR, page order, reassembly |
| R-Studio Technician | Rebuilt the FAT volume, which brought back the volunteers' own naming as well | Reads nearly every file system, and rebuilds arrays you can rely on |
How it went.
Deciding between the memory and the controller
Nothing came back over USB, so the plastic came off and the board went on the bench under probes. Talked to directly, the memory answered at once and named itself as a part we already hold a profile for. Its neighbour, the controller, said nothing. The way the fault had arrived — saves first, reads later — had pointed that way already.
Get the pages off first, sort out the ledger after
A raw dump is not a disk image. Every page arrives with its error-correction bytes still attached, hidden behind whatever XOR mask this particular controller applied, and in a sequence laid down by a translation layer that no longer exists. Correct the errors, lift the mask, put the order back — a file only appears once all three are done.
Restore the volume, then check file by file
With the dump corrected and back in sequence, the FAT tables read properly again and the archive came up under the group's own file names. Checking was manual, one item at a time: the registers, the magazines, the typed interviews. A file that fails to open is not a recovery, however good the totals look.
Signing it off.
The whole lot went back on new media. Since then the group has voted its own rule into the minutes: keep three copies, and one of them off the premises. The worn-out stick is kept in a drawer now, as a reminder.
Pages people often read next.
Next to SSD & flash.
Is that what yours is doing?
Power it down, get it to us, and hold off on any decision until the diagnosis says what can still be read.