Flash and SSD · job record · PLY-2025-0918
Writing Failed in March, Everything Else by June.
Everything the Kingsbridge history group had gathered lived on one stick — parish registers photographed a page at a time, catalogues from old shows, and the memories of the town's older residents, typed up over a succession of winters. What failed, failed in sequence. In March the laptop they use at meetings would not accept anything new
. Come June, folders had started refusing to open. All it will say now is USB device not recognized
.
Sounds like yours? Talk it through.
0800 6890668
Why it happens.
The sequence is the diagnosis. Flash is worn down by writing and not by reading: every program-and-erase cycle takes a slice out of a cell's life, while a read takes none. Writes going in March and access going in June is therefore the signature of a stick that has been used up. For as long as spare blocks remain, the controller quietly retires the worn ones and puts its translation tables wherever the silicon still holds up. When the spares run out the tables go with them, and the stick stops answering on the bus. What the screen is reporting is a controller with nothing left to say. It says nothing whatever about the scans.
The kit this job called for.
How the job runs →| The kit | What it did here | Why we keep it |
|---|---|---|
| PC-3000 Flash | Identified the NAND from its library entry, then read the chip after removing it from the board | Bypasses the controller and reads the raw NAND, against a maker-ID library we keep up to date |
| Rusolut Visual NAND Reconstructor | Removed the XOR mask and restored the page order the silent controller had been using | Turns a raw NAND dump back into data: ECC, XOR, page order, then reassembly |
| R-Studio Technician | Reassembled the FAT volume, and the volunteers' own naming came back with it | Reads nearly every file system, and rebuilds RAID sets from images |
How it ran.
Was it the memory that had gone, or the controller
Nothing came back over USB at all, so the casing came away and probes went on the board. Approached directly, the memory replied at once with a part number already sitting in our library. Beside it the controller said nothing. The sequence the symptoms had come in — writing gone, then reading — had already indicated as much.
Get the pages off, sort out their order afterwards
A chip read is not a disk image yet. Each page arrives with its error-correction bytes attached, hidden behind an XOR mask the controller picked, and placed where a translation layer that is now gone decided to put it. Fix the errors, take off the mask, put the sequence back. Get all three right and files appear; get two of the three right and you have nothing.
Reassemble the volume, then open each item
With errors corrected and the sequence restored, the FAT tables read properly and the archive turned up under the names the group had chosen for it. Checking was done by hand, one item at a time: registers, catalogues, the typed-up interviews. A count on its own means little. A file nobody can open has not been recovered.
How it ended up.
The whole archive travelled back on fresh media. A rule now stands in the group's own minutes: three copies, one of them kept somewhere other than the meeting room. The worn stick is in a drawer now, held on to as a note of the order in which it gave up.
Pages people open after this.
Other SSD & flash jobs.
Seeing the same thing?
Leave it switched off and post it in. Nothing happens until the diagnosis, which lists what can still be read and what cannot.