Data Recovery Case File · Solid State & Flash · The Port It Was In
Disconnected in an Expansion Port and Never Seen Again
His enquiry includes a detail about timing that anyone would find hard to write. A 256GB stick holding two years of photographs and work: "I recently plugged it into a USB expansion port, and then it disconnected, and since then no computer system is even acknowledging that a USB is plugged into it. Sadly I ordered an external drive to have a backup before this problem occurred, so it was very unfortunate timing." The backup was on its way and did not arrive in time. And the port it was in when it died is a genuine part of the story, not an incidental detail.
| Media | 256GB USB flash drive holding approximately two years of photographs and work — disconnected while in an expansion hub and not enumerated on any host since |
| Reported situation | Stick connected through a USB expansion port · disconnection occurring during use · no enumeration on any computer since · no indication of a device being present · photographs and work held |
| Fault class | Controller failure following a power event — memory readable independently of the controller |
| Equipment used | No further connection attempts · current draw measured on a controlled bench supply · memory packages read at chip level past the controller · translation layer reconstructed in software · files validated by opening |
The decode: why hubs do this, and where the files are
What total absence means: when anything is connected, the host supplies power and waits for the device to introduce itself. If that exchange completes even partially, the system lists something — including an unrecognised or malfunctioning device. His produces nothing at all on any machine, which means the introduction never begins. That places the failure in the stick's controller or its power path, before any question of files or filesystems arises.
Why the expansion port matters, and this is worth knowing: hubs and expansion ports are a common place for small devices to die, for two reasons. An unpowered hub splits the current available from a single host port between everything attached, so a device drawing near its limit can be starved — and brown-out conditions, where a device receives enough power to start and not enough to run, are considerably harder on electronics than no power at all. A powered hub introduces its own supply, and a failing or poor-quality one can deliver out-of-specification voltage directly into whatever is plugged in. Either produces exactly this: a device that was working, disconnected during use, and never came back.
What follows practically: the hub should be treated as suspect and not used for anything else that matters until it has been proven on something disposable. If it damaged one device it can damage another, and people routinely replace the stick and lose the replacement the same way.
Why the files are very likely intact: a stick contains two distinct things — the controller, which conducts the introduction and manages the memory, and the memory packages, which hold the data. Electrical events kill controllers far more readily than memory, because the controller sits on the power path and the memory sits behind it. So a stick that has stopped introducing itself has usually lost the part that talks, not the part that remembers.
How that is reached: the memory packages are read directly on a programmer, bypassing the controller entirely. What comes back is raw — scrambled, error-coded, and organised by the controller's own scheme — so it is descrambled, error-corrected and reassembled in software through the translation layer until the filesystem stands up.
What not to do: not keep trying it, and above all not try it in that hub again.
On the bench
No further connection was attempted, since a device producing nothing at all on multiple hosts has already established the position. Current draw was measured on a controlled bench supply rather than a host port, distinguishing a controller drawing nothing from one drawing abnormally — which follows a power event and tells you whether the power path or the controller logic failed. The memory packages were then read at chip level past the controller, and the result descrambled, error-corrected and reconstructed in software through the translation layer. Files were validated by opening.
The outcome
Current draw established on a controlled supply, the memory read past the failed controller and the files reconstructed and validated. Free assessment, one fixed written figure including VAT, 50% of parts and labour upfront with the balance only on successful recovery. The decode, for anyone whose stick died in a hub: the port is part of the story. Unpowered hubs split current between everything attached, and brown-out conditions are harder on electronics than no power at all; powered hubs can deliver out-of-specification voltage directly into whatever is plugged in. Treat that hub as suspect. And take encouragement from what failed — electrical events kill controllers far more readily than memory, so the part that talks has gone rather than the part that remembers.
Device that died in a USB hub or expansion port
Don't use that hub again until you've proved it on something you don't care about — people replace the stick and lose the replacement the same way. Hubs are a common place for small devices to die. An unpowered one splits the current from a single host port between everything attached, and a device that gets enough power to start but not enough to run is in a brown-out condition, which is harder on electronics than no power at all. A powered hub brings its own supply, and a failing one can push out-of-specification voltage straight into whatever is connected. The encouraging part is what tends to fail: electrical events kill the controller far more readily than the memory, because the controller sits on the power path. So the part that talks has gone, not the part that holds your files.
Stop using that hub — call Newcastle Data Recovery on 0191 406 1051; current draw measured on a controlled bench supply, memory read at chip level past the controller, files checked by opening.
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.