Home / Case Studies / Solid State & Flash
Solid State & Flash · case file

It Only Shows Up Sometimes, Then Vanishes

A 64GB stick with research photographs and audio on it. Most Windows machines do not see it at all; one or two show it in Device Manager for a few seconds before it disappears again. Intermittent enumeration is the classic signature of a failing controller, and it is the point at which plugging it in again stops being harmless. A USB stick is two components: memory chips that hold the data, and a controller that presents them to the computer and keeps track of where everything actually sits. When the controller starts to fail, the memory is usually in perfect condition behind it. The stick appears, cannot complete its start-up, and drops off. Each further attempt is another chance for it to fail in a way that takes the mapping with it, and that mapping is what makes the raw memory readable.

USB FlashNot DetectedElectrical / PCB
// case at a glance
Media64GB USB flash drive holding research photographs and audio. Not detected on most machines; appears briefly in Device Manager on a few.
Reported situation64GB USB stick · not discovered on most Windows machines · appears briefly in Device Manager on some · research photographs and audio needed · recovery sought.
Fault classFailing flash controller. The chip presenting the memory is giving out, so the stick enumerates briefly or not at all, while the data usually remains intact in the memory. Reached by reading the memory directly at chip level past the controller. Repeated plugging in is the risk.
Equipment usedExamined under the microscope at magnification, controller and memory package identified · memory read at chip level past the failing controller, the chip lifted off with hot air and read on a dedicated flash programmer · the controller's translation rebuilt and the data descrambled · photographs and audio carved out by content signature in PhotoRec, opened and played back to confirm they were usable, then written to fresh media.
// the decode

The decode

Flash memory does not store files the way a hard drive does. The controller spreads data across the memory in a pattern of its own choosing, moves it around constantly for wear levelling, and keeps a translation table describing where everything currently lives. Read the memory chips raw and you get the right bits in the wrong order, scrambled and interleaved according to that controller's private scheme.

Which is why a failing controller is a specific kind of problem. The data is intact — flash does not forget because the controller is ill — but the map is inside the component that is dying. Recovery means reading the memory directly, then reconstructing the translation from first principles: identifying the controller family, working out the interleaving and the scrambling, and reassembling the image until a recognisable file system appears.

The reason to stop plugging it in is that a partially failing controller can still write. Each attempt to enumerate involves the controller updating its own tables, and a failure part-way through that can corrupt them or trigger a wear-levelling operation that shuffles data. It is a small risk per attempt and it accumulates, and there is no benefit at all to set against it — a stick that appears for three seconds is not going to let you copy 64GB off it.

This is bench work with a physical stage: the chip is lifted off with hot air and read on a dedicated flash programmer, which is why it counts as physical work in pricing terms. It is also worth being clear that this is a flash package on a small board, not storage soldered onto a computer's motherboard — the latter is the one thing outside our intake, and it is a different situation entirely.

// on the bench

On the bench

It went under the microscope at magnification first, where the controller and the memory package were identified and the board checked for anything else that had failed. The memory was then read directly at chip level, past the controller entirely, with the chip lifted off with hot air and read on a dedicated flash programmer. The raw dump was descrambled and the controller's translation rebuilt until a coherent file system emerged. The research photographs and audio were carved out by content signature in PhotoRec where structure was missing, and every file was opened — images rendered, audio played back — before anything counted as recovered. The results went to fresh media.

// the outcome

The outcome

Memory read at chip level and the research files recovered onto fresh media. The assessment cost nothing and ended with one fixed written figure for the fault found before any work began. Chip-level work consumes bench time and destroys the stick in the process, so it is priced as physical work with half the figure due at the outset and the balance only on a result. Worth saying plainly for anyone with research or fieldwork on a single stick: flash memory is not archival storage. It fails without warning, it fails completely, and the only defence is a second copy somewhere else.

A stick that only shows up sometimes

Stop plugging it in. Every attempt gives a dying controller another chance to fail in the middle of updating its own tables, and those tables are what make the raw memory readable afterwards. Do not try it on ten different computers to find one that works — the fault is in the stick, not in the ports. Do not run recovery software during one of the brief windows when it appears, because a tool writing or even reading hard at that moment can finish it off. Keep the stick somewhere safe, note what was on it and roughly what the files were, and send it. And if the material is research or fieldwork, take the wider point: one copy on flash is not storage, it is a gamble with a deadline.

Got one of these on your desk right now? Everything here follows the same route: an assessment you are not charged for, completed inside 2 working days of the box reaching the bench, after which you get one written figure that never climbs afterwards. Logical faults are handled on no fix, no fee. Should the casing need opening, or the electronics rebuilding after a drop, a surge, a soaking or a fire, half of that figure falls due first and the rest only once your data is in hand. Ransomware, camera and DVR recorders, BitLocker volumes and anything else classed as forensic get settled in advance, in full. Where the files live inside a machine — laptop, desktop, Mac, server — pull the drive or the SSD and post that by itself. Computers are not dismantled here, and flash fixed permanently onto a logic board (the newer Apple laptops among them) is the one category refused outright. Unscrews or unplugs and we will take it. Send it tracked and insured to Edinburgh Data Recovery, 4 Redheughs Rigg, Westpoint, South Gyle, Edinburgh EH12 9DQ, arrange and pay for a courier of your own, or bring it to the counter there. No device is ever fetched from a customer. Packing notes and the shipping form sit here.
Start a free diagnostic

Each file below comes from a genuine enquiry taken from households and firms across Aberdeen, Aberdeenshire and the wider north-east, anonymised so nobody can be identified. Each one sets out how the fault was reasoned through, what was done about it, and which equipment did the work.

// related case files

Nearby files worth a look

Browse all case studies →

Recognise your own drive in this one?

Assessment is free and takes 2 working days at most once it lands, the figure is fixed in writing, and logical work carries no fix no fee. Begin online, or lift the phone.