SSD & flash · bench log · MHD-2025-6918
It Would Not Save, and Then It Would Not Open.
Everything a heritage group near Ascot had assembled was on one stick: parish log books photographed page by page, wartime magazines, interviews with older residents typed up over several winters. It went in the order these things usually go. Back in March the library computer would not accept any of the new scans
; by June nothing would open; now it produces only the notice USB device not recognized
.
Much the same fault? Call us.
0800 6890668
In everyday terms.
That notice describes a controller that has stopped answering. It says nothing about the photographs behind it. The order of events is the useful part: flash degrades on the write, not the read, because programming a cell erodes it in a way that reading never does. A stick that loses saving months before it loses opening is behaving as worn flash behaves. While sound blocks remain, the controller retires the tired ones and keeps its own translation tables somewhere safe; when it runs out of somewhere safe, it stops enumerating at all.
What the bench used here.
How a job is handled →| Tool | Why we used it | What it brings |
|---|---|---|
| PC-3000 Flash | Identified the NAND from its markings and read it off the board | Reads the NAND chips directly, matched against a maker-ID library that is kept up to date |
| Rusolut Visual NAND Reconstructor | Undid the XOR masking and the page interleave the dead controller had applied | Turns a raw NAND dump into readable files: ECC, XOR, page order, reassembly |
| R-Studio Technician | Rebuilt the FAT volume so the names the volunteers had typed came through | Its file-system coverage is wide and its array rebuilds hold up |
The lab work.
Establish which half of the device had died
With nothing coming back over USB, the casing was opened and the board went under the probes. Contacted directly, the memory answered and matched a known part on the first attempt; it was the controller alongside it that would no longer respond. The order in which the symptoms had arrived predicted precisely that.
Lift the pages raw, then undo the housekeeping
What comes off the chip bears no resemblance to a disk image. Every page carries error-correction bytes, every page is masked with an XOR pattern of the controller's choosing, and the order they belong in lived in a translation layer that died with it. Correction, then unmasking, then re-ordering, before anything file-shaped appears.
Reassemble the volume, then open everything
With the dump corrected and re-ordered, the FAT structures resolved and the archive reappeared under the names its volunteers had chosen. Verification was done by hand, item by item — log books, magazines, transcripts — on the principle that a file which will not open has not been recovered.
How the job closed.
The complete archive travelled back on fresh media. The group has since minuted a rule of its own: three copies at all times, one of them kept elsewhere. The failed stick sits in the box as a reminder.
More of the jobs we've closed.
Filed beside SSD & flash.
Does any of that match your case?
Nothing needs deciding until the diagnosis is back: switch the device off, send it in, and let the findings settle it.