Data Recovery Case File · Solid State & Flash · The Log Names the Stage
It Failed at the First Question It Was Asked
His enquiry includes something almost nobody sends: the actual system log. A stick "not even being recognised as a device", accompanied by kernel messages recording a new device appearing, followed by a failed device descriptor read and an error code. That is far more specific than "not recognised" — it means the device drew power, announced itself electrically, and then failed the very first question the host asked it.
| Media | USB flash drive — electrical presence detected by the host; device descriptor exchange failing; enumeration not completing |
| Reported situation | Stick not recognised as a device · host log recording a new device detected on the bus · descriptor read failing with a communication error · enumeration not completing · error reproducing consistently · contents required |
| Fault class | Enumeration failure at the descriptor exchange — controller powering and not responding coherently; memory unaffected |
| Equipment used | Host log accepted as evidence of enumeration stage reached · no repeated connection attempts · signal integrity and current draw measured on a controlled bench supply · chip-level read past the controller · translation layer reconstructed in software |
The decode: what a descriptor read is, and why failing it is informative
What happens in the first moments after connection: the host detects a device electrically and assigns it a temporary address. It then asks the device to send its descriptor — a short block stating what kind of device it is, who made it, and what it can do. Everything else depends on that exchange succeeding. Nothing about storage, capacity or filesystems is discussed until it has.
What his log shows: the device was detected — the host logged a new device and assigned it a number — and then the descriptor read failed with a communication error. So the stick has power and is present on the bus, and it either did not respond, responded with something malformed, or the response was corrupted in transit.
Why that is a narrower finding than "not recognised": a device that is genuinely absent produces no log entry at all. This one got far enough to be noticed and numbered. The failure is at the protocol level rather than the electrical one, which is a meaningful distinction and one that only the log reveals.
What causes it, in order of likelihood on a stick: the controller powering up but not executing correctly — most often because it cannot read the configuration it needs before it can describe itself. Less commonly, damage affecting the signal path so the response is corrupted. Occasionally a power problem where the device cannot sustain the current required to respond.
Why the memory is untouched regardless: a controller that cannot answer its first question has not written to or erased anything. The failure is in the component that speaks for the memory, not the memory itself — and on a stick that component can be bypassed entirely.
What that route is: reading the memory directly through the manufacturer's test points, past the controller, then descrambling, error-correcting and reassembling in software with the addressing pattern reconstructed from the contents themselves.
Why sending the log was worth doing, and worth copying: most enquiries describe an outcome; this one describes a stage. Anybody on a system that keeps such logs can retrieve them in a few seconds, and the difference between "nothing happens" and "it was detected and failed the descriptor read" is the difference between a guess and a diagnosis.
On the bench
The host log was accepted as evidence of the enumeration stage reached — a device genuinely absent producing no entry at all, so a logged detection followed by a failed descriptor read places the failure at the protocol level rather than the electrical one. No repeated connection attempts were made. Signal integrity and current draw were measured on a controlled bench supply, and the memory read at chip level past the controller with the translation layer reconstructed in software.
The outcome
The enumeration stage established from the log, draw and signal integrity measured, and the memory recovered past the controller. 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 host detects a device, assigns it an address, and then asks it to describe itself — that descriptor exchange is the first question, and everything depends on it. Yours got as far as being detected and numbered before failing to answer, which puts the fault in the controller rather than the memory.
Device that isn't recognised, with a log to show for it
Keep that log and send it — it turns a guess into a diagnosis, and on systems that keep one you can retrieve it in seconds. A device genuinely absent produces no entry at all, so an entry showing it was detected and assigned a number, followed by a failed descriptor read, tells you the stick has power and is present on the bus. The descriptor is the first question a host asks: what kind of device are you, who made you, what can you do. Nothing about storage or capacity is discussed until that succeeds. Failing there points at the controller rather than the memory — and on a stick the memory can be read past the controller entirely.
Send it with your enquiry — call Guildford Data Recovery on 01483 901310; enumeration stage established from the log, draw and signal integrity measured, memory read at chip level past the controller.
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.