Data Recovery Case File · Solid State & Flash · Where the Live Document Is
Before the Stick, Find Out What the Application Still Has
Her enquiry describes a failure that happened mid-sentence. A memory key that "stopped working while I had it plugged into my computer and was working on a document. It's not recognised by the computer any more, and after trying to plug it in again I got a message that the device is damaged and not recognised." The document she was editing may still exist on the computer — and that is worth establishing before anything at all is done about the stick.
| Media | 16GB USB flash drive — failing during active use with a document open; host reporting the device as damaged and unrecognised on reconnection |
| Reported situation | Stick connected and in use · document being edited from the stick at the time · device ceasing to function during that session · not recognised on reconnection · host reporting the device as damaged · connections inspected by the owner |
| Fault class | Failure under active read and write load — enumeration fault reported at the host; working document potentially retrievable from host application artefacts |
| Equipment used | Host application recovery and temporary locations enumerated before any device work · connector condition assessed under magnification · device addressed through hardware with imposed timeouts · chip-level read past the controller where enumeration failed |
The decode: the free check first, and what failing under load means
Why the computer comes before the stick: she was editing a document when it failed. An application working on a file does not read it once and forget it — it holds a working copy in memory, and it writes autorecovery versions and temporary files to the computer's own drive at intervals, regardless of where the original lives.
So what may be sitting on the machine: a version of the document from minutes before the failure. Office software maintains autorecovery copies in a configured location and temporary working files alongside, both hidden by default, and neither is affected by what happened to the stick.
Why this is urgent rather than merely worth trying: those files are transient. They are cleaned up on restart, on the application being opened again, and by ordinary system maintenance — so the window is measured in days and shrinks with every use of the computer.
Where to look, in order: the application's autorecovery location, set in its preferences; the folder the document was last saved to; and the system temporary folder, with hidden items shown. Names are unhelpful and extensions are frequently wrong, so sorting by modification date is the fastest route.
Now the stick, and what failing under use tells us: it was reading and writing when it stopped. Devices fail under load rather than at rest — a marginal controller manages an idle connection and gives up when asked to sustain work, which is why so many failures happen during transfers and editing rather than on connection.
What the message means: the host detected the device electrically and did not receive a usable response during identification. It is reporting a failure to introduce itself, which places the fault at the controller or the connection rather than in the memory.
Why she was right to inspect the connections: connector joint fatigue is the commonest physical failure on these devices and it is visible under magnification. Checking is free and it either finds something or narrows the field.
What must not happen: no repeated insertion, and no tools offering to repair it. The stick is not going to behave differently on the fifth attempt.
On the bench
Host application recovery and temporary locations were enumerated before any device work — applications holding a working copy in memory and writing autorecovery and temporary files to the host's own drive irrespective of where the original resides, with those artefacts transient and removed by restarts and ordinary maintenance. Connector condition was assessed under magnification, and the device addressed through hardware with imposed timeouts.
The outcome
Host application artefacts enumerated before any device work, the connector assessed under magnification, and the memory read past the controller where required. 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: look at the computer first. An application editing a file holds a working copy in memory and writes autorecovery versions to the machine's own drive — so a version from minutes before the failure may be sitting there, and those files do not last.
Device that failed with a document open on it
Search the computer before doing anything about the device — and do it today. An application editing a file keeps a working copy in memory and writes autorecovery versions and temporary files to the machine's own drive, wherever the original was stored, so a version from minutes before the failure may still be there. Those artefacts are transient: restarts, reopening the application and ordinary maintenance remove them. Look in the application's autorecovery location from its preferences, the folder you last saved to, and the temporary folder with hidden items shown, sorting by date rather than name. Then stop reinserting the stick.
Search the computer first — then call Oxford Data Recovery on 01865 593000; application artefacts enumerated before any device work, connector assessed under magnification, memory read past the controller where needed.
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.