Data Recovery Case File · Laptop Drives · The Command-Line Campaign

Plumbing repairs over a flooding basement: a competent boot-repair campaign, and why none of it could work

This customer's enquiry doubled as a lab notebook. His four-year-old laptop's Toshiba drive had taken longer than normal to shut down; next boot, Windows attempted repairs and failed; Startup Repair declared the drive locked; then "No Bootable Device." From a recovery USB he ran the canonical trilogy — bootrec /FixMbr, /FixBoot, /RebuildBcd — without result, and chkdsk, which reported no notable issues bar "a couple of bad clusters." Every step competent, every step documented — and every step aimed one storey above the actual fault. The campaign deserves grading, because thousands run it weekly.

The campaign, command by command

Startup Repair, and "the drive is locked." Grade: informative failure. On a machine with no encryption in play, that message is the recovery environment's way of saying it cannot get a coherent read of the system volume — not a security state but a legibility one, and the campaign's first genuine clue that the problem lived below the software. The bootrec trilogy. Grade: correct tools, wrong storey. FixMbr, FixBoot and RebuildBcd repair the plumbing of starting — the small structures that tell a machine where Windows lives — and they're the right answer when those structures alone are damaged. When the volume beneath them can't be read reliably, they're re-fitting taps above a flooding basement: each reported "success" was the command completing its little write, changing nothing about the floodwater. chkdsk: "no noticeable issues… a couple of bad clusters." Grade: the smoking gun, filed as a footnote. Bad clusters are hardware-failed regions — on a system drive, even a couple visible to a surface-level scan implies more beneath, and it retro-explains the entire timeline: the slow shutdown was Windows fighting to flush its final writes onto failing media; everything after was consequence. The campaign's one structural flaw wasn't any command — it was continuing to run write-capable repairs on a drive whose own evidence said the media was going.

The recovery

Reframed as hardware, the job ran this archive's slow-fail discipline: the drive imaged on the PC-3000 through the USB Stabilizer with its self-maintenance silenced — healthy expanses banked at pace, the bad-cluster neighbourhoods and their unadvertised relatives negotiated last with bounded patience — and the system volume reconciled on the image, where "locked" dissolved into ordinary, repairable filesystem damage the moment its underlying sectors could actually be served. His user profile — documents, photos, the four-year accumulation the campaign had been fighting for — came off complete and verified, delivered on new media while the laptop itself gained a fresh drive and a clean install.

Outcome

Everything recovered, and a rule of thumb for every future command-line campaigner: when correctly-run boot repairs change nothing, stop repairing — the fault has just told you it lives below their reach. And give bad clusters their proper weight: in any scan's output, on any drive that matters, "a couple" is not reassurance — it's the visible edge of the reason you're in the recovery environment at all. His notebook-quality documentation, for the record, cut our diagnosis time in half. The only edit it needed was the conclusion.

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.