Data Recovery Case File · Solid State & Flash · One Event, Two Suspects
A Machine Failing and a Drive Failing at the Same Moment Need Separating
His enquiry describes a single event that could have two causes. A solid-state drive no longer recognised, where "the computer reported a critical failure and shut down, and now the drive is not recognised" — with an awareness that this model's controller has a reputation for stopping abruptly. The machine may have failed and taken the drive down, or the drive may have failed and brought the machine down, and which came first changes what the fault is.
| Media | 120GB solid-state drive holding approximately 60GB — not recognised by host firmware following a reported critical failure and shutdown |
| Reported situation | Machine reporting a critical failure and shutting down · solid-state drive not recognised afterwards · drive absent from host firmware · roughly half the drive's capacity occupied · controller family known for abrupt failure · contents required |
| Fault class | Controller ceasing to respond — device absent from firmware following an abrupt system event; memory not implicated by controller state |
| Equipment used | System failure and device failure separated by sequence before any conclusion · device addressed through hardware with imposed timeouts rather than the host stack · controller state assessed in vendor technological modes · chip-level read past the controller with translation layer reconstructed in software |
The decode: which failed first, and why it hardly changes the route
The first possibility — the machine took the drive down: a system experiencing a critical failure and shutting down abruptly removes power from everything attached. A solid-state drive interrupted while its controller was updating internal structures can be left unable to complete its start-up afterwards, which is a genuine mechanism and a common one.
The second possibility — the drive took the machine down: a system drive that stops responding mid-operation leaves the operating system waiting on a device that has gone silent. That is exactly the condition that produces a critical failure and a protective shutdown, so the machine's collapse may have been a symptom rather than a cause.
Why the second reading is well supported here: he notes that this controller family is known for stopping without warning. Where a device has a documented tendency to fail abruptly, a simultaneous system failure is more plausibly its consequence than its cause — the machine reported a problem because the drive stopped answering.
Why the sequence matters less than it seems: both routes end in the same place. A controller that is no longer responding is the fault either way, and the work of reaching the memory behind it is identical.
What absence from firmware establishes: the machine's own start-up routine, running before any operating system, finds no drive. Nothing above the device is implicated — no filesystem, no partition, no operating system — and the drive is simply not identifying itself.
Why the memory is very likely intact: the failure is in the controller, the component that manages and speaks for the storage. Memory packages are separate components and are not implicated by a controller unable to complete its start-up, which is the basis of the route past it.
What that route is: the drive addressed through hardware that does not depend on the controller answering, the controller assessed and where necessary bypassed, and the memory read directly with the pattern by which content was distributed rebuilt in software.
Why the drive being half empty helps slightly: less occupied capacity means less to reconstruct and a cleaner reassembly. Sixty gigabytes across a hundred and twenty is a favourable ratio for rebuilding the arrangement.
What must not happen: no repeated power cycles to see whether it appears, no vendor repair or firmware update attempted against it, and no initialising if the machine offers. A controller stuck at start-up stays stuck, and a firmware operation on a device in this state is a write to the one component that is failing.
On the bench
System failure and device failure were separated by sequence before any conclusion — an abrupt shutdown removing power mid-operation and leaving a controller unable to complete start-up, or equally a controller ceasing to respond and leaving the operating system awaiting a silent device, which itself produces a critical failure and protective shutdown. Both terminate in an unresponsive controller. The device was addressed through hardware with imposed timeouts, and chip-level reading performed past the controller.
The outcome
The two failures separated by sequence, the device addressed through hardware, and the memory read past the controller. 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: the machine and the drive failed together, and either could have caused the other. Both end in an unresponsive controller — which is not the memory holding your files, and that is why a route past it exists.
A drive that vanished when the computer crashed hard
Don't attempt a firmware update or vendor repair on it, and stop power-cycling — a controller stuck at start-up stays stuck, and a firmware operation writes to the very component that's failing. Either explanation of the event leads to the same place: an abrupt shutdown can interrupt a controller mid-update and leave it unable to start, while a controller that stops answering leaves the system waiting on a silent device, which itself triggers a critical failure. If your drive is absent from the machine's start-up screen, nothing above the device is involved. The memory packages holding your files are separate from the controller that failed.
Don't run a firmware repair — call Easy Data Recovery on 028 9002 0144; the two failures separated by sequence, addressed through hardware with imposed timeouts, memory read past the controller.
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.