Data Recovery Case File · Solid State & Flash · The Error Blames the Wrong End
An Error Message Pointing at the Wrong Device
His enquiry quoted the error, and the error is misleading. Copying around 20GB of photographs and video from a 64GB card taken out of a phone: "it attempts to copy, then I get a message saying the destination you have specified does not exist, it may be an offline network location. If I skip those files it tries again, and then the card drops out and is not visible unless you remove and re-insert. I presume the card is somehow faulty." His presumption is right and the message is not. Nothing is wrong with the destination — the card is resetting under sustained reading, and the copy operation reports the failure at the wrong end.
| Media | 64GB memory card removed from an Android handset — copy operations failing partway with a destination error; device dropping from the bus and requiring reinsertion; approximately 20GB of photographs and video held |
| Reported situation | Card read through an adapter · copy operations failing partway · host reporting a destination or network error · card dropping out and requiring physical reinsertion to reappear · photographs and video required |
| Fault class | Device resetting under sustained read load — controller instability; file copying unable to complete, imaging under timeout control indicated |
| Equipment used | Copying discontinued · imaged write-blocked under strict per-sector timeouts (DeepSpar USB Stabilizer 10Gb) · dropouts absorbed by resumable imaging across multiple passes · contents validated by rendering and playback |
The decode: what the message really means, and why copying cannot work
Why the error names the destination: because the copy operation lost its handle to a device and reported the failure generically. Wording of that kind is written for network drives disappearing mid-transfer, and it gets reused whenever a source or destination stops responding. Here the source vanished — the card dropped off the bus while being read — and the message blamed the far end. People spend a long time investigating a destination that was never involved.
What the dropout actually is: the key symptom, and he described it precisely. A card that disappears and only returns after physical removal and reinsertion has reset. Its controller encountered a condition it could not handle, stopped responding, and required a full power cycle to restart. That is a controller-level instability, and it is provoked by exactly what he was doing: sustained continuous reading of large files.
Why copying can never finish: this is the part worth understanding. A file copy is all-or-nothing per file — it opens a file, reads it through, and if the device vanishes mid-way the file fails and the operation moves on or stalls. Retrying restarts from the beginning of that file, provoking the same reset at roughly the same point. So the process cannot converge. Skipping the problem files, as he tried, simply moves the same failure to the next large one, and each cycle is another reset of an unstable controller.
What works instead: imaging rather than copying, with strict per-sector timeouts and resumption across passes. An imager reads the device as a sequence of sectors rather than as files, keeps a map of what it has captured, and when the device drops it waits, allows it to re-enumerate, and resumes from where it stopped instead of restarting. Large video files that no copy could ever complete are assembled across multiple passes. The dropouts are absorbed rather than fought.
Why the file sizes matter here: photographs are small enough to copy between resets, which is why some material may already have transferred. Video files are large and continuous, so they are the ones that consistently fail — worth checking the destination for what did arrive before commissioning anything.
What to stop: reinserting and retrying. Each reset cycle is an unstable controller being power-cycled under load, and the elimination is already complete.
On the bench
Copying was discontinued, since a file copy restarts from the beginning of a file after each dropout and provokes the same reset at the same point, which cannot converge. The card was imaged write-blocked behind the DeepSpar USB Stabilizer 10Gb under strict per-sector timeouts, with dropouts absorbed by resumable imaging — the imager holding a map of captured sectors, waiting through each reset, allowing re-enumeration and resuming rather than restarting. Large video files were assembled across multiple passes, and contents validated by rendering and playback.
The outcome
The card imaged under timeout control across multiple resumed passes, and the photographs and video validated and delivered. 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, for anyone getting a destination error while copying from a card: the message is pointing the wrong way — copy operations reuse network-flavoured wording whenever a device stops responding, and here it is the source that vanished. A card that only returns after reinsertion has reset its controller under sustained reading, which is why copying can never finish: each retry restarts the same file and provokes the same reset.
Card that drops out partway through copying
Stop retrying, and don't spend time investigating the destination — that error message is pointing at the wrong end. Copy operations reuse network-flavoured wording whenever a device stops responding, so a card vanishing mid-read gets reported as a problem with where you were copying to. What's actually happening is that the card's controller has hit something it can't handle and reset, which is why it only comes back after you physically remove and reinsert it. That's provoked by exactly what you're doing: sustained reading of large files. Copying can't succeed here, because each retry restarts the same file and triggers the same reset at the same point, and skipping just moves it to the next large file. Check what already transferred, though — small photographs often make it between resets even when video never does.
Stop retrying — call Newcastle Data Recovery on 0191 406 1051; imaged write-blocked under strict timeouts, dropouts absorbed by resumable passes, large files assembled across multiple reads.
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.