Data Recovery Case File · Solid State & Flash · A Well-Designed Test
A Crash of the System Itself Places the Fault Deeper Than an Application Hang
His enquiry describes a controlled investigation with a consistent result. A secondary drive that crashes a desktop outright, where "disconnected, the desktop starts fine. I tried it through an adapter both before and after starting up and it still crashes — and it crashes a laptop too." Those are well-chosen tests, and a fault that brings down the operating system rather than merely hanging a program is misbehaving at a level applications never reach.
| Media | 1TB solid-state drive used as secondary storage — causing system-level crashes on connection across multiple hosts and connection methods |
| Reported situation | Solid-state drive used as secondary storage rather than for startup · host crashing when the drive is connected · host starting normally with the drive disconnected · adapter connection attempted both before and after start-up · crashes occurring in both cases · second machine of a different generation also crashing · recovery of as much content as possible sought |
| Fault class | Device misbehaving at bus level — system-level crashes rather than application faults; response invalid or absent in a manner the host cannot handle gracefully |
| Equipment used | System-level crash distinguished from application-level hang to locate the fault · connection sequence tests accepted as excluding start-up handling · 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: what each of his tests removed, and what the crash type means
Why disconnecting it and starting normally was the foundational test: it establishes that nothing else is wrong. The machine, its own drive and its operating system are all sound, and the fault arrives with the device — which he proved rather than assumed.
Why connecting before and after start-up was the sharper test: those are handled by different parts of the system. A drive present at start-up is examined by the initialisation process; one attached afterwards is handled by the running system's device management — and a fault appearing in both cases is not a quirk of either path.
Why the second machine mattered: a different generation of the operating system on different hardware. Identical behaviour there removes the specific system version, the specific drivers and the specific machine in one step.
What a system-level crash indicates that a hang does not: the fault reached the part of the system with no protection above it. An application that waits forever on a device hangs and can be closed; the system halting means something invalid arrived where invalidity cannot be handled — which is a device returning malformed responses rather than simply failing to answer.
Why that is a meaningful distinction for the diagnosis: a silent device produces timeouts and stalls. A device answering incorrectly produces crashes, because the system acts on what it receives — and a controller in a confused state can report impossible capacities, invalid completions, or malformed data that the host takes at face value.
Why the drive being secondary is fortunate: it holds no system files, so nothing depends on it. It can be removed entirely with no consequence to the machine, which he has already done — and there is no pressure to make it work in place.
Why the memory is very likely intact: the misbehaviour is in the controller, the component that manages and speaks for the storage. Memory that holds data is not implicated by a controller giving invalid answers, which is the basis for reaching it another way.
What that route is: the drive addressed through hardware that does not hand its responses to a general-purpose operating system. A controller returning malformed data cannot crash equipment built to expect it, and the memory is read directly with its distribution pattern rebuilt in software.
What must not happen: no further connection to any working computer. Each attempt risks the host rather than the drive — an abrupt system crash can leave the machine's own filesystem inconsistent, which turns one problem into two.
On the bench
A system-level crash was distinguished from an application-level hang to locate the fault — an application awaiting a silent device hanging recoverably, whereas a halt of the system itself indicates invalid data reaching a level with no protection above it, consistent with a controller returning malformed responses rather than failing to respond. Connection sequence tests were accepted as excluding start-up handling, initialisation and running device management being separate paths. Chip-level reading was performed past the controller.
The outcome
The crash type used to locate the fault, the sequence tests accepted as excluding host handling, 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: a crash of the system rather than a hang is the informative part. A silent device produces stalls; one answering incorrectly produces crashes, because the system acts on what it is given.
A drive that crashes the computer it is connected to
Stop connecting it to working machines — each attempt risks the host rather than the drive, since an abrupt crash can leave the computer's own filesystem inconsistent and turn one problem into two. Your tests were the right ones though: starting normally without it proves the machine is sound, connecting before and after start-up covers two separate handling paths, and a second machine removes the system version and drivers. A crash rather than a hang is diagnostic in itself — a silent device causes stalls, while one returning malformed answers causes crashes, because the system acts on what it receives.
Stop connecting it — call Easy Data Recovery on 028 9002 0144; crash type used to locate the fault, 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.