Case record · SSD & flash · SDR-2025-0639
The SSD No Laptop Will Accept.
It had been having trouble booting up properly
, and then it died outright. The owner did the sensible thing and tried on other computers with the same result
— a second laptop, then a USB caddy, and not recognised in the system
each time. A repair shop had already said it couldn't help
.
Seeing the same thing yourself?
0800 6890668
The translation.
Testing a suspect disk in a second machine, and a known-good disk in the first, is the sharpest diagnosis anyone can manage without a lab — and here it pointed straight at the SSD's controller. That chip is the go-between: it presents the flash to the computer and keeps the table linking logical addresses to physical pages. Controllers give up long before the memory they manage does. Getting at that memory, though, has nothing in common with platter work — no surface to read, nothing mechanical to put right.
Kit used on this job.
What happens in a case →| Platform | Its role in this case | Why we use it |
|---|---|---|
| PC-3000 SSD | Coaxed the controller into a service mode and read the flash sitting behind it | Reaches SSD controllers directly, on media with no platter to read |
| PC-3000 Flash | Identified the memory against an up-to-date database and supported the raw read | Pulls data straight from memory chips, with a current library that identifies them automatically |
| UFS Explorer Professional Recovery | Put the file structure back together once the mapping had been rebuilt | Handles the difficult filesystems better than most — APFS, ReFS, XFS, ZFS, Btrfs |
In the lab.
Establish that the fault is the controller and not the flash
The disk was examined at controller level, never through a host port. It was stalling partway through its own start-up routine — the point at which an SSD reads in its mapping tables and makes itself ready to answer. Nothing pointed to flash that had been worn out or harmed.
Persuade the controller into a state that will talk
The platform's maker-specific commands were used to drop the controller into technological mode — the service state in which it hands over memory contents it will not serve in ordinary use. That single step is what divides recovering an SSD from simply replacing one.
Rebuild the mapping, then the file tree
Raw flash contents are meaningless until the layer that orders them is restored, so the mapping came first and filesystem work second. Only after that was the NTFS volume put back together, with folders and files standing in their proper places rather than as loose fragments.
The result.
Everything the owner wanted came back in full, returned on fresh media. The Latitude was never at fault and started up happily on a new disk — and the swapping he had already done spared us a diagnostic step.
Similar cases on the index.
Also from SSD & flash.
Does this sound like your own drive?
The rule holds as in every case above: switch it off, and let a free diagnosis come before any decision.