Devices · solid-state & NVMe
Nothing to hear, nothing to see. The machine boots on Friday and on Monday the drive is not in the list. Three things usually explain it: the controller has failed, the firmware has corrupted itself, or the mains went mid-write. Western Digital and Crucial account for most of what comes in from Birmingham. The work happens at the flash, and early beats late.
Tell an engineer what it is doing
0800 6890668
| What you see | What is behind it | What to do |
|---|---|---|
| The drive now calls itself SATAFIRM S11 | Only one meaning: the Phison controller is stuck in ROM mode | Keep the manufacturer's tool away |
| Nothing shows in the BIOS | Controller or firmware, almost always; the flash below it is untouched | This is chip-level work |
| Capacity reads 0GB, or a size that makes no sense | Its translation layer — the FTL — has given way | Stop the restarts |
| SMART health falls off a cliff | Genuine wear, or a controller talking nonsense | Read the maker's advisory, then image it |
| SSD reads fail: 0x800701E3 | The failure is at hardware level | Image it; keep repair tools off |
| Boot device not found, after a firmware update | A firmware write that stopped halfway left no bootable copy | Keep it powered off |
Every item gets a case number of its own the day it lands. An engineer then works out what has actually failed and tells you plainly which files have a real chance of coming back and which do not. Only then does a price follow: one figure, fixed, in writing, and it costs you nothing to see it. Nothing is charged until you say yes.
Every restart costs a struggling drive a little more ground. It goes into a controlled service mode instead, and from there the flash takes its orders from the bench rather than from firmware that can no longer manage.
When the controller will not answer, we read the flash straight off and rebuild the translation table in code. A raw dump on its own is static. Put the table back and the folders reappear.
One document ends up spread over every die on the board — that is wear levelling doing its job. The fragments are put back into sequence, the volume rebuilt, and every entry checked off against a listing.
No invoice is raised until the full list of recovered files has sat in front of you and you have said go ahead. Your data comes back on media we buy new, posted at our expense, and the job is not closed here until every file has opened on your own machine.
The risk worth knowing about: a firmware flash overwrites the region that tracks where every file sits, and if the mains drops halfway through there is no older copy underneath to fall back on. Most updates finish cleanly. Take a copy off the drive before you start one, and leave well alone if the drive is already playing up.
A firmware update stopped part-way through and left the laptop's system SSD unreadable. Its translator tables were rebuilt in technical mode, and a decade of edited catalogues belonging to one photographer came back whole.
Possibly — but only if you cut the power now, not this evening. TRIM has the drive wiping the blocks behind a deleted file on its own, something no mechanical disk does, and it carries on while the power stays on. This is the one occasion where yanking the lead out is right.
Rarely. When a drive stops announcing itself, the controller or the firmware has gone, and the NAND underneath is usually in perfect order. Go at those chips directly and most of the contents come straight back.
It is a different job, not a harder one. Hard drives break in their moving parts; SSDs break in the controller and the tables it keeps. Provided TRIM has not been through, the odds hold up well.
Yes. Those go through with the laptop and Mac work — the same chip-level approach, done with the memory left where it is.
Every extra power-up takes something off a drive that is already going. Leave it switched off and let the free diagnosis say what still reads.