Data Recovery Case File · Solid State & Flash · Earlier Than the Operating System
The Machine Is Not Crashing — It Is Waiting
This enquiry came from an IT provider working on a client's machine, and it describes a device causing trouble before any software is involved. A solid-state drive that "causes multiple PCs to freeze at start-up. When connected using a caddy the drive intermittently appears in the file browser where we can see the data, however it disconnects before we are able to copy." Halting at that stage is a firmware behaviour, not a fault in the machine — and the caddy getting further explains itself once you know why.
| Media | 480GB solid-state drive — halting host firmware initialisation on direct connection; enumerating intermittently through an external adapter; disconnecting during transfer |
| Reported situation | Drive fitted internally causing multiple hosts to halt during firmware initialisation · drive connected through an external adapter presenting intermittently · content visible when presented · connection dropping before transfer completes · business accounting data required |
| Fault class | Controller responding intermittently — firmware initialisation blocking on unanswered identification; asynchronous adapter path permitting brief windows |
| Equipment used | Direct internal connection avoided after the halt was reproduced · enumeration windows characterised under strict timeouts · priority material identified before any capture attempt · chip-level read past the controller where windows proved insufficient |
The decode: why firmware halts where an operating system would not
What happens during firmware initialisation: before any operating system exists, the machine's own firmware enumerates attached storage — asking each device to identify itself and report its capacity, so it knows what is available to boot from. It does this sequentially and it waits for each answer.
Why a non-answering device stops everything: that code is minimal by design, with no scheduler, no threads and very generous timeouts, because at that point in a machine's start-up nothing else is running to be inconvenienced. So a drive that does not identify itself is not skipped — it is waited for, and the whole machine sits there. What looks like a freeze is a computer being patient.
Why it happened on multiple machines: they all do the same thing. That is a proper elimination — the fault travelled with the drive across hosts, and the behaviour is inherent to how firmware handles storage rather than to any one computer.
Why the external adapter gets further, which is the useful part: external connection is handled by a fully-running operating system with its own timeouts, error handling and the ability to give up. An unresponsive device on that path is a device that failed to enumerate, not a stalled machine — so the system carries on, and each retry is another chance for the drive to answer during one of its working moments.
What "appears intermittently" tells us: the controller is working sometimes. That is not a device that has failed completely — it is one that succeeds occasionally, which means every appearance is an opportunity and an unknown number remain.
Why copying through the file browser wastes them: a normal copy starts at the beginning and works through, so a window that closes mid-way leaves whatever it happened to reach. The windows are the resource, and they are being spent on the wrong material in the wrong order.
What to do with the next one: identify the specific files needed before connecting again. Accounting data is usually a small number of named files in a known location, and reaching those first turns an unpredictable window into a result.
What must stop: fitting it internally. Every attempt is a machine held for minutes and a drive asked to answer at its least reliable.
On the bench
Direct internal connection was avoided after the halt was reproduced — firmware initialisation enumerating storage sequentially with minimal error handling and generous timeouts, so an unanswering device is waited for rather than skipped. Enumeration windows were characterised under strict timeouts, an intermittently responding controller offering an unknown and finite number of opportunities. Priority material was identified before any capture attempt, and the memory read at chip level past the controller where windows proved insufficient.
The outcome
The internal path abandoned, windows characterised under controlled timeouts and priority material identified before capture. 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 machines are not crashing, they are waiting. Firmware enumerates storage before any operating system exists, sequentially and patiently, so a drive that will not identify itself holds the whole start-up. Your caddy gets further because a running system can give up.
Drive that halts any machine it is fitted to
Stop fitting it internally and work through an adapter instead — and before you connect it again, write down exactly which files you need. Those machines aren't crashing, they're waiting: firmware enumerates storage before any operating system exists, asking each device to identify itself, and that code has no scheduler and very generous timeouts because nothing else is running to inconvenience. A drive that won't answer is waited for rather than skipped. An adapter gets further because a fully running system can time out and carry on. Your intermittent appearances are a finite resource, so spend them on named files in known locations rather than a copy that starts at the beginning.
Don't fit it internally — call Oxford Data Recovery on 01865 593000; enumeration windows characterised under strict timeouts, priority material identified before capture, memory read past the controller where needed.
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.