Data Recovery Case File · Portable Drives · Order of Events
The Computer's Fault May Have Become the Drive's
His enquiry records a sequence most people would not think to write down, and it is the whole case. A drive that "was reading fine. The USB controller it was connected to stopped responding, so I switched the drive to another port, and it then started clicking." He has since taken it out of its enclosure and connected it directly. A failing port is not a neutral event for whatever is plugged into it — and the clicking beginning immediately afterwards is unlikely to be a coincidence.
| Media | Portable hard drive removed from its enclosure — reading normally until the host interface controller failed; head positioning failure beginning immediately afterwards |
| Reported situation | Drive reading normally in use · host interface controller ceasing to respond · drive transferred to an alternative port by the owner · clicking beginning at that point · drive removed from its enclosure and connected directly · contents required |
| Fault class | Head positioning failure following host supply irregularity — damage plausibly consequent on the interface failure rather than independent |
| Equipment used | No further connection attempts on any host · laminar flow bench inspection of heads, surfaces and spindle before any spin attempt · matched donor parts as indicated · imaging in one supervised session on independently regulated supply |
The decode: how a port failure reaches a drive
What a bus port provides: data and power. A portable drive draws everything it needs — the motor, the head positioning, the controller — from that connection. The supply is not incidental to it; it is the whole of it.
Why a failing controller is dangerous rather than merely inconvenient: controllers do not always stop cleanly. One that is failing may deliver voltage that sags under load, fluctuates, or drops without warning while continuing to appear present. The moment before a controller stops responding is frequently a period of unstable supply, and a drive is running throughout it.
What that does to a mechanism: a drive losing power in the ordinary way parks its heads safely — there is enough residual energy in the spinning platters to retract them, and the design depends on it. That safety margin assumes a clean loss. A supply that sags rather than stops can leave the drive without enough to park properly while the platters are still turning, and heads that do not retract cleanly are heads that may contact the surface.
So the likely sequence: the controller degraded, the drive experienced unstable supply, the heads failed to park or were disturbed, and by the time he moved it to a working port the damage was already done. The clicking he heard on the new port was the first opportunity to hear it, not the moment it happened.
Why moving ports was entirely reasonable: it is the obvious response to a port that has stopped responding, and on almost every occasion it is the right one. Nothing about his reaction was wrong — the damage had a cause upstream of him.
What is worth taking from it: if a port or controller fails while a drive is connected, treat the drive as potentially affected rather than simply relocating it. Listen before reconnecting, and if anything sounds different, stop there. The instinct to move it to another port is an instinct to keep using it, and a drive that has just been through an unstable supply is a drive to leave alone.
Why taking it out of the enclosure was good work: connecting it natively removes the enclosure's own bridge and power arrangement from the question, which matters here because a supply event is exactly what could have damaged those too.
On the bench
No further connection attempts were made on any host. The drive was opened under the laminar flow bench with heads, surfaces and spindle inspected before any spin attempt — a failing interface controller frequently delivering unstable supply before ceasing to respond, and a drive without clean power lacking the residual energy to park its heads safely while platters are still turning. Matched donor parts were fitted as indicated, and imaging performed in one supervised session on an independently regulated supply.
The outcome
The mechanism inspected before power, serviced with matched parts and imaged on an independently regulated supply. Free assessment, one fixed written figure including VAT, 50% of parts and labour upfront with the balance only on successful recovery. The decode: your port didn't just stop, it degraded — and a controller that is failing can deliver supply that sags under load while still appearing present. A drive relies on residual energy in its spinning platters to park its heads safely, and that assumes a clean loss of power. Moving to another port was the reasonable response; the cause was upstream of you.
Drive that started clicking after a port stopped responding
Don't reconnect it, and know that the order of events matters here. A port supplies both data and power, and controllers don't always fail cleanly — one that's degrading can deliver voltage that sags under load or drops without warning while still appearing present. A drive relies on the residual energy in its spinning platters to retract its heads safely when power goes, and that safety margin assumes a clean loss; an unstable supply can leave it without enough to park while the platters are still turning. So the damage likely happened before you moved it, and the clicking on the new port was simply the first chance to hear it. Moving ports was the reasonable thing to do.
Leave it disconnected — call Guildford Data Recovery on 01483 901310; inspected before any spin attempt, serviced with matched donor parts, imaged on an independently regulated supply.
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.