Data Recovery Case File · Solid State & Flash · The Software Is Not the Problem
A Drive That Stops Responding Mid-Operation Takes Whatever Is Reading It Down Too
His enquiry lists three tools that each fail in the same way. A solid-state drive that stopped working after the machine was switched off at the power button, where "recovery software just crashes, an automatic repair black-screens, and a caddy gives no access either." Software does not crash because a drive has no data on it — it crashes because the drive stops answering mid-request, and a program waiting on a device that has gone silent hangs or falls over.
| Media | 240GB solid-state drive — unresponsive across recovery software, automatic repair and an external adapter; failure following an abrupt power-off |
| Reported situation | Solid-state drive corrupted after the machine was powered off at the button · recovery software crashing when run against it · automatic repair proceeding to a black screen · drive inaccessible through an external adapter · contents required |
| Fault class | Controller entering an unresponsive state mid-operation — host and software failures downstream of the device dropping off the bus; memory unaffected |
| Equipment used | Software and host failures interpreted as the device dropping off the bus rather than tool faults · 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: why everything that touches it fails the same way
What people conclude when software crashes: that the software is faulty, or that the drive is so badly damaged there is nothing to read. Neither is what is happening, and trying more tools produces the same crash for the same reason.
Why a program crashes on this drive: recovery software, repair utilities and ordinary file access all send the drive a request and wait for a response. When the drive stops answering partway through, the program is left waiting on a device that has gone silent — and depending on how it handles that, it hangs, times out, or crashes.
Why three different tools all fail: they share the same dependency. Every one of them talks to the drive through the operating system, and inherits the system's behaviour when a device drops off the bus — so the fault is not in any of the tools, it is in the thing they all rely on.
Why the caddy fails too: an external adapter changes the connection, not the drive. A controller that stops responding does so regardless of how it is attached, so moving it to a caddy produces the same silence through a different cable.
What "stops answering partway" indicates: the drive's controller enters an unresponsive state during operation. On a solid-state drive this frequently follows an interruption — and being switched off at the power button, as he describes, is exactly the kind of abrupt event that can leave a controller unable to complete its start-up afterwards.
Why the automatic repair black-screening fits: the repair began, sent the drive a request, and the drive stopped responding — so the repair process itself hung, taking the screen with it. Same cause, different symptom.
Why the memory is very likely intact: the fault is in the controller, the part that manages and speaks for the storage. The memory holding the data is a separate component and is not implicated by a controller that cannot complete its start-up — which is why the route past it exists.
What that route is: the drive addressed through hardware that imposes its own short timeouts and does not hang when the device goes silent, the controller assessed and where necessary bypassed, and the memory read directly with its addressing pattern reconstructed.
What must stop: further tool attempts and further repairs. Each is the same request to the same unresponsive controller, and the repair in particular writes.
On the bench
Software and host failures were interpreted as the device dropping off the bus rather than tool faults — recovery software, repair and file access all issuing a request and awaiting a response, so a controller ceasing to answer mid-operation leaves each waiting on a silent device and hanging or crashing, with all three sharing the host as a common dependency. The device was addressed through hardware with imposed timeouts rather than the host stack, and chip-level reading performed past the controller.
The outcome
The crashes read as the device dropping off the bus, the drive addressed through hardware rather than the host stack, 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 software isn't faulty. A drive that stops answering mid-request takes whatever is reading it down with it, and three tools fail the same way because they all wait on the same silent device.
When every tool crashes on the same drive
Stop trying more of them — they'll fail identically, because the problem isn't the software. Recovery tools, repair utilities and ordinary file access all send the drive a request and wait for an answer, and they all talk to it through the operating system. When the drive's controller stops responding partway through, each is left waiting on a silent device and hangs or crashes, and a caddy changes only the cable, not the drive. On a solid-state drive this often follows an abrupt power-off. The controller is what's stuck; the memory holding your data is a separate component and usually intact, which is why reading past the controller works. Don't run the repair again — it writes.
Stop trying tools — call Easy Data Recovery on 028 9002 0144; crashes read as the device dropping off the bus, 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.