Data Recovery Case File · Desktop Externals & Aging Drives · Two Detections, One Device
Startup Detection and Operating System Detection Are Separate Events With Separate Deadlines
His enquiry reports two machines disagreeing about whether a drive exists. After a power loss the drive "didn't recover, gone from the firmware", yet connected to a second machine "a partition manager picks up the physical drive, but no partition available", with a device error and nothing further. Both observations are correct: firmware detection happens on a short timer at startup, and a drive slow to become ready misses it while still being present afterwards.
| Media | Desktop hard drive following supply interruption — absent from host startup detection; enumerating as a physical device on a second machine with no partition presented |
| Reported situation | Machine losing power during use · drive not recovering on restart · drive absent from startup firmware listing · drive connected to a second machine · partition management software detecting the physical device · no partition presented · input-output error reported without further detail |
| Fault class | Delayed readiness with partition structures unreadable — device present and responding slowly; startup detection window missed while operating system detection succeeds |
| Equipment used | Firmware absence distinguished from device absence by the second machine's detection · current draw measured across the start-up cycle on a controlled bench supply · service area read under strict timeouts with extended readiness allowance · imaged write-blocked at the block level under capped timeouts · partition structures recovered from residual volume records |
The decode: why one machine sees it and the other does not
What startup firmware does: asks briefly. It polls attached devices during a short window and moves on, because a machine cannot wait indefinitely to start.
Why a slow drive fails that test: readiness takes time. A drive must spin up, calibrate and read its own configuration before it can answer, and a drive doing that slowly answers after the window has closed.
Why the operating system succeeds where firmware failed: it is more patient. Software enumeration allows far longer and retries, so a device too slow for startup is frequently detected once a system is running.
Why that makes his two observations compatible: nothing contradicts. Gone from firmware and present to software describes one drive answering slowly, and the second machine is the more informative test.
Why slow readiness after a power loss is expected: the drive was interrupted. An abrupt cut can leave a drive with configuration it must reconcile at the next start, and reconciliation takes time.
What no partition available means alongside that: the device responded and its partition record did not resolve. The physical device is addressable and the description of how it is divided is not readable.
Why that is a separate layer from the detection question: one concerns the device and the other the structures on it. A drive can be perfectly detectable with an unreadable partition table, and both are consistent with an interrupted write.
Why the input-output error without detail is consistent too: it reports a read that did not complete. A generic device error is the system saying the drive did not answer in time, which is the same slowness in another form.
Why the content is very likely intact: the partition table is a small structure at the start of the drive. Files occupy regions nothing in this account has touched.
What must not happen: no initialising and no partition creation. Software that detects a device without partitions will offer to create them, and accepting writes over the records being reconstructed.
On the bench
Firmware absence was distinguished from device absence by the second machine's detection — startup firmware polling attached devices within a short fixed window, while a drive must spin up, calibrate and read its configuration before answering, so slow readiness misses that window. Operating system enumeration allows longer and retries, detecting devices firmware does not. Absence of a partition concerns structures rather than the device. Service area was read with extended readiness allowance.
The outcome
Firmware absence distinguished from device absence, draw measured across the start-up cycle, and partition structures recovered from residual volume records. 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: both machines are right. Startup firmware asks briefly and gives up, while an operating system waits and retries — so a drive that has become slow to be ready disappears from one and not the other.
A drive missing at startup but visible to another machine
Don't initialise it or create a partition when software offers — that writes over the very records needed to rebuild your volume. Treat the disagreement as informative rather than confusing: startup firmware polls devices within a short fixed window because a machine can't wait indefinitely to boot, while an operating system waits much longer and retries. So a drive that has become slow to become ready vanishes from one and appears in the other. After a power loss, slow readiness is expected, since the drive has configuration to reconcile.
Don't initialise it — call Cambridge Data Recovery on 01223 655015; firmware absence distinguished from device absence, read with extended readiness allowance, partitions recovered from residual records.
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.