Devices · solid-state and NVMe drives
There is nothing to listen for with an SSD. You shut the machine down as usual; next morning the BIOS has no drive on its list. Three faults cover most of what reaches us: a controller that stops, firmware that corrupts, power that goes mid-write. The same three turn up across London, on an instrument PC in a Croydon industrial unit and on a family machine in Enfield, and more of them carry a WD or Crucial badge than anything else. All the work happens at the flash, and it goes better early than late. A single drive is £300 + VAT after the free look.
Put it to an engineer — the first look costs nothing
0203 0868633
| What is going on | The usual reason for it | Where that leaves you |
|---|---|---|
| It names itself SATAFIRM S11 | Only one cause: a Phison controller fallen back on its ROM | Keep well away from the vendor utility |
| The BIOS shows nothing at all | Almost always controller or firmware, with the flash behind it sound | This becomes chip-level work |
| Shown as 0GB, or at a plainly wrong size | The flash translation layer, which records where everything physically sits, has failed | Stop the restarting |
| Its SMART health figure drops overnight | Either real wear on the NAND, or a controller reporting nonsense | Look up the maker's advisory, then image |
| Every read gives 0x800701E3 | That code is hardware | Image it, and run no repair tool at all |
| Boot device not found, and it started after a firmware update | A firmware write that stopped half-way, and now nothing boots | Keep it switched off |
A case number goes on it the day the parcel lands, and an engineer settles what has truly failed before anything else happens — free of charge, and first in the order of work. Back to you come two things together: a straight note of what is liftable and what is not, plus one figure, fixed and written down. Accept it, or decline and owe us nothing.
Every power-on takes something from a failing drive. Here it is instead brought up in a vendor service mode, which lets the bench address the flash directly and keeps worn firmware out of the conversation.
With no answer from the controller, every chip gets addressed separately and software reconstructs the translation table. By itself a raw dump means nothing. Return its table and the folder tree returns with it.
Wear levelling exists to spread a single document over every die on the board, and that is what it does. Order is then put back a piece at a time, the volume is reassembled, and each entry is set against the listing that goes out with the job.
What was recovered is listed for you first, and only then does a bill exist. Approve the list and it is invoiced; turn it down and it is not — and where nothing has come back, most jobs carry no charge whatever. Recovered data travels home on fresh media bought in for your job, with the postage at our end. Your case is not closed until you have read those files on a machine of your own.
Before you accept an update: flashing rewrites where your data physically sits, and should power drop half-way there is no earlier copy beneath it. The great majority go through without trouble, so take this as no reason to skip updating — just copy your files off beforehand. The one drive that should never be put through it is one already misbehaving.
The laptop's system SSD went silent partway through a firmware update, and nothing more would read off it. Technical mode reopened a route in for an engineer, who put the translator tables back together until the flash underneath could be mapped by the controller once more. A photographer's decade of edits opened first time.
Possibly not, but the window here is hours rather than days. TRIM is the reason: leave an SSD powered and it works through the blocks that held your deleted file, clearing them to a schedule nobody asked for. No spinning disk ever behaved that way. Pulling the plug is usually the wrong reflex; on this one fault it is the right one.
Seldom. Silence generally points at the controller, or at the firmware, with the flash untouched behind them. Reading those chips is bench work, and most of what they were holding comes back.
Different, not harder. A hard disk gives out at its moving parts. An SSD gives out at the controller, or in the tables the controller maintains. So long as TRIM has not already been through those blocks, the outlook is reasonable.
Those arrive here too and go through beside the Mac and laptop work. Nothing about the task at the flash changes; what changes is that the chips remain where they are and are read there.
Looking at it is free. Back comes a list of what opened and what did not, together with a single price to finish, set down in writing while you are still free to say no. On most jobs an invoice only follows the data. Until that list reaches you, leave the drive switched off.