Data Recovery Case File · Solid State & Flash · Capture in Fragments
It Never Stays Long Enough to Be Useful
Her enquiry describes a device that works constantly and never usefully. A 128GB stick that "has started mounting and unmounting, so it's pretty much unusable. I tried different ports, different machines, and a Mac, but I haven't been able to figure out what's going on as it doesn't stay on long enough to complete a basic scan. I also haven't been able to get any of the data off for a backup, because it keeps unmounting itself." Everything conventional fails here for the same reason — every tool assumes the device will still be there when it finishes, and this one will not.
| Media | 128GB compact-format USB flash drive — cycling between enumeration and disconnection continuously; no operation completing before the device drops |
| Reported situation | Stick mounting and unmounting repeatedly and continuously · behaviour reproduced across ports, machines and platforms · scanning unable to complete · file copying unable to complete · no data retrieved |
| Fault class | Controller instability producing repeated reset cycles — capture requiring resumable fragmentary reads rather than continuous operations |
| Equipment used | Conventional copying and scanning discontinued · imaged write-blocked under strict timeouts with resumable session capture (DeepSpar USB Stabilizer 10Gb) · fragments accumulated across cycles into a single image · thermal duty cycle managed between sessions · files validated by opening |
The decode: what the cycling is, and why the usual tools cannot work
What mounting and unmounting repeatedly means: the controller is enumerating, running for a short period, and then resetting or dropping off the bus — after which the host sees a new device arrive and the cycle repeats. The device is not dead and it is not working. It is restarting, continuously.
The common causes: a controller that faults during its own operation and resets; unstable power delivery, either from the port or from a failing regulator on the device; or heat. The last is worth taking seriously on a compact stick, because those pack a fast controller into a tiny metal body with no thermal mass and no airflow — they warm quickly and shed heat poorly, and a controller reaching its limit will reset rather than continue.
Why every conventional approach fails, and it is not her doing anything wrong: copying, scanning and repairing all assume continuity. A copy started on a device that vanishes mid-operation fails and starts again from the beginning; a scan that needs ten minutes on a device that lasts ten seconds never gets past the first fraction; a repair utility cannot write to something that is not there. Each attempt covers the same opening portion repeatedly and then dies.
What works instead, and it is the whole answer: abandoning continuity as a requirement. Capture is performed in resumable fragments — each successful enumeration used to read whatever can be read before the device drops, with the position recorded, and the next cycle continuing from there rather than restarting. Dozens or hundreds of short reads accumulate into one complete image. What is captured is permanent; what is not is attempted on the next cycle.
Why the duty cycle is managed deliberately: where heat is a contributor, working the device continuously through its cycles makes them shorter. Allowing it to cool between sessions lengthens each usable window, and a longer window means more captured per attempt.
What she should stop doing: further copying and scanning attempts. They cannot succeed by their nature, and each one works a controller that is already resetting under its own operation.
Why the outlook is reasonable: the memory is not the problem. A controller that resets repeatedly has not damaged what is stored, and once the contents are assembled from an image the instability is irrelevant.
On the bench
Conventional copying and scanning were discontinued, both assuming a device that persists and each attempt covering the same opening fraction before the device dropped. The stick was imaged write-blocked under strict timeouts behind the DeepSpar USB Stabilizer 10Gb with resumable session capture — each enumeration used to read from the last recorded position, so fragments accumulated across cycles into a single image rather than restarting. Thermal duty cycle was managed between sessions, cooling lengthening each usable window. Files were validated by opening.
The outcome
The capture accumulated in resumable fragments across cycles into a single image, with the duty cycle managed and files validated by opening. Free assessment, one fixed written figure including VAT; where a chip has to be removed, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode: a device cycling between mount and disconnect is a controller resetting continuously — running briefly, faulting, and restarting. Every conventional tool assumes continuity, so a copy restarts from the beginning each time and a scan never gets past the opening fraction. Capture has to work in resumable fragments instead.
Device that keeps mounting and unmounting
Stop trying to copy or scan it — those can't succeed here by their nature, and each attempt works a controller that's already resetting under its own operation. What's happening is that the device enumerates, runs briefly, faults and drops off the bus, after which the host sees a new device arrive and the cycle repeats. Every conventional tool assumes the device will still be there when it finishes, so a copy restarts from the beginning each time and a scan never gets past its opening fraction. The approach that works abandons continuity: read whatever is possible in each short window, record the position, and continue from there next cycle. Heat is often a contributor on compact sticks, so letting it cool lengthens each window.
Stop copying — call Guildford Data Recovery on 01483 901310; imaged in resumable fragments accumulated across cycles, duty cycle managed between sessions, files validated 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.