Data Recovery Case File · Formatted & Logical Faults · It Stops the Machine
A Drive That Freezes the Firmware Is Failing to Finish Introducing Itself
His enquiry describes a symptom sharper than the usual absence. A drive holding a virtualisation filesystem and several virtual machines, which "spins up but hangs the firmware on detection" — leading him to suspect the controller. Hanging is more specific than not being detected: the drive answered enough to start the exchange and did not answer enough to finish it, and the machine is left waiting.
| Media | 2TB hard drive holding a virtualisation filesystem with multiple virtual machine images — rotating on power-up and halting host firmware during device enumeration |
| Reported situation | Drive holding a virtualisation filesystem and several virtual machines · drive rotating on power-up · host firmware halting during device detection · controller failure suspected by the owner · content required |
| Fault class | Incomplete enumeration halting the host — device responding partially and not completing identification; firmware-stage or board fault indicated |
| Equipment used | Halting treated as partial response rather than absence · device addressed through hardware with imposed timeouts rather than host firmware · service area and identification data read under strict timeouts · imaged write-blocked at the block level with virtual machine images kept whole · virtualisation filesystem interpreted from the image |
The decode: why hanging differs from absence, and what the content adds
What happens during detection: the firmware asks each device to identify itself and waits for a reply. A device that is absent produces no reply and the firmware moves on after a short interval — which is why a dead drive is simply not listed.
What his drive did instead: began responding and stopped. Firmware waiting on a partial exchange has no timeout worth the name and waits indefinitely, which presents as the whole machine hanging.
Why that is genuinely informative: partial response requires the drive to be alive. Power, rotation and the beginning of communication all work, and the failure is in completing identification.
Why his suspicion is reasonable: identification data is read by the drive from a reserved area before it can answer. A drive unable to read that region cannot complete the exchange, and the fault sits in the board and firmware rather than in the recording.
Why that region is a small target: it holds configuration rather than content. Its unreadability says nothing about the areas where his virtual machines sit, which are elsewhere and untouched by this failure.
Why the drive must not be connected to a machine again: each attempt hangs the host, requiring a forced restart. Forced restarts with a partially-responding drive attached risk the machine's other volumes, and the attempt gains nothing.
What is done instead: the drive is addressed through equipment that imposes its own timeouts and does not depend on host firmware. A device that hangs a machine can be communicated with in a controlled environment, and its reserved area read directly.
Why the content type changes the imaging requirement: a virtual machine is a single enormous file. A partial read of a hundred-gigabyte image yields a file that will not start, where a partial read of a photograph folder yields most of the photographs.
Why that raises the stakes on completeness: the tolerance for missing regions is far lower. Imaging must aim to capture each virtual machine file entirely, and unreadable regions within one are worth many passes.
Why the arrangement is nonetheless helpful: virtualisation filesystems store each machine as a small number of large contiguous files. They are simple to locate and simple to keep whole, which is more than can be said for a general-purpose volume.
On the bench
Halting was treated as partial response rather than absence — firmware asking each device to identify itself and moving on after a short interval where none replies, so an indefinite wait indicates an exchange begun and not completed, which requires the device to be alive. Identification data is read by the drive from a reserved area before it can answer, so unreadability there prevents completion while saying nothing of content regions. Imaging kept virtual machine images whole.
The outcome
Halting treated as partial response, the device addressed through hardware with imposed timeouts, and imaging performed with virtual machine files kept whole. Free assessment, one fixed written figure including VAT; where a drive has to be opened, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode: hanging is better news than absence. Your drive began the identification exchange and could not finish it, which means it is alive and cannot read its own configuration region.
A drive that freezes a machine during detection
Stop connecting it, since each attempt requires a forced restart and forcing a machine down with a partially-responding drive attached risks its other volumes. Read the hang as informative: firmware moves on quickly from a device that doesn't reply at all, so an indefinite wait means the exchange began and didn't finish — which requires the drive to be alive. What it can't complete is reading its own identification data from a reserved area, a small region holding configuration rather than content. If you hold virtual machines, insist on completeness: one is a single huge file, and a partial read won't start.
Stop connecting it — call Manchester Data Recovery on 0161 871 0788; halting treated as partial response, addressed through hardware with imposed timeouts, virtual machine images kept whole.
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.