Data Recovery Case File · Solid State & Flash · Present but Not Answering
Visible to the System, Returning Nothing
His enquiry was written by someone who has already narrowed the problem properly. A failing NVMe solid-state drive: "the drive is physically detected by the system but returns 0 bytes read." Those two facts sit either side of a boundary that matters enormously, and stating both is the most useful thing an owner can do. Being detected and being readable are separate achievements, and a drive that manages the first and not the second has failed in a specific, well-understood place — one that is usually more tractable than a drive which has vanished entirely.
| Media | NVMe solid-state drive — enumerated and identified by the host while returning no data on read operations |
| Reported situation | Drive physically detected by the system · identification succeeding · read operations returning nothing · data recovery sought |
| Fault class | Identification succeeding with media addressing failing — translation layer or firmware state rather than absent memory |
| Equipment used | Access attempted in vendor technological and safe modes (PC-3000 portfolio, SSD support) · firmware area and translation-layer assessment · imaging on restored addressing · contents verified by opening |
The decode: two handshakes, and which one failed
What detection actually requires: less than people assume. To be detected, a drive must accept power, complete its start-up sequence far enough to respond, and answer the host's identification enquiries — what it is, what model, what capacity. That is a conversation between the host and the drive's controller, and it involves no user data at all. A drive that gets this far has working power, a running controller and functioning communication.
What reading requires that detection does not: the controller must consult its translation layer — the internal map converting the logical addresses a computer asks for into physical locations in the flash memory — and then actually fetch from those locations. Solid-state drives never store data where the computer thinks it is; wear levelling moves everything constantly, and the map is what makes the drive coherent. If that map is corrupt or unreadable, the controller can still hold a conversation about who it is while being unable to find anything.
Why returning zero bytes rather than errors is informative: a drive with failing memory typically returns some data and errors on the rest. One returning nothing at all, consistently, is not describing damaged storage — it is describing a controller that cannot resolve any address. That points squarely at the management layer rather than at the NAND, and the memory holding his files is very likely intact behind it.
Why this is the better of the two solid-state failures: the route exists. Manufacturers build technological and safe modes into their controllers for exactly this — a way to address a drive whose normal start-up cannot complete, assess its firmware area, repair the damaged modules and rebuild the translation state. Once that succeeds the drive addresses its media normally and images conventionally.
The honest counterpart, stated before rather than after: where the failure lies in the memory itself, or where the controller's own encryption state is unrecoverable, reading the flash packages directly is not the dependable fallback it is on cards and sticks. On an SSD the mapping and often the keys live in the controller, so raw NAND without them is not reassemblable. That is why this class of drive is assessed rather than promised.
What he should not do meanwhile: leave it powered, run repeated scans, or allow any tool to attempt a firmware update or a secure erase. All of those act on a controller already in a confused state, and a secure erase in particular is exactly what it sounds like.
On the bench
Access was attempted through the PC-3000 portfolio's SSD support in the drive's vendor technological and safe modes, since a drive that identifies consistently while returning nothing is describing a controller that cannot resolve addresses rather than absent memory. The firmware area and translation layer were assessed specifically, the damaged modules repaired, and the translation state rebuilt until the drive addressed its media normally. Imaging followed on restored addressing and the contents were verified by opening.
The outcome
The controller addressed in vendor modes, the translation state rebuilt and the contents imaged and verified. Free assessment, one fixed written figure including VAT; where a chip has to be removed, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode, for anyone whose drive is seen but reads nothing: detection and reading are separate achievements — identification is a conversation with the controller involving no user data, while reading requires the internal map that converts logical addresses to physical flash locations; a drive returning zero bytes consistently rather than a mixture of data and errors is describing a broken map rather than damaged memory, which is the more tractable failure. Don't leave it powered, and never let anything attempt a firmware update or secure erase.
Drive the system sees but can't read
Report both halves of that, because together they narrow things usefully — and take some encouragement from the combination. Being detected only means the drive accepted power, started up far enough to respond, and told the computer what it is; that's a conversation with its controller and involves none of your data. Reading needs something more: the internal map that converts the addresses your computer asks for into physical locations in the flash, because solid-state drives never store data where the system thinks it is. A drive returning nothing at all, consistently, is describing a broken map rather than damaged memory, and that's the more recoverable of the two. Don't leave it powered, don't run repeated scans, and never allow a firmware update or a secure erase.
That's the map, not the memory — call Newcastle Data Recovery on 0191 406 1051; addressed in vendor technological modes, firmware and translation layer assessed, imaged on restored addressing.
Request a quote online →
Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.