Data Recovery Case File · Cameras, Drones & Cards · It Failed While Being Read
A Card That Fails During an Upload Was Being Asked to Read All of Itself
Her enquiry places the failure precisely in time. A card holding around eleven hundred images in two formats, where "about four hundred photos through the upload process it stopped and could no longer be read" — and it no longer works in the camera either. An upload is the one operation that reads a card end to end, which is why faults surface during it rather than during ordinary shooting.
| Media | Camera memory card holding approximately 1,100 images in raw and compressed formats — failure occurring approximately 400 images into a transfer; not subsequently readable in camera or computer |
| Reported situation | Card holding approximately 1,100 images in two formats · transfer to a computer commenced · transfer stopping approximately 400 images in · card no longer readable by the computer · card no longer working in the camera · content from the preceding day required |
| Fault class | Controller failure during sustained reading — fault surfacing under full-card access; content written normally beforehand |
| Equipment used | Failure during transfer treated as sustained-read stress rather than transfer error · card removed from use immediately · addressed through hardware with imposed timeouts rather than the host stack · memory read past the controller where indicated · raw and compressed images carved separately and validated by opening |
The decode: why uploads find faults, and where the boundary sits
Why an upload is more demanding than a day's shooting: shooting writes in bursts with long gaps, touching a small area at a time. An upload reads every occupied region continuously, at speed, for as long as it takes — the heaviest sustained demand a card ever receives.
Why that makes uploads the place faults appear: a controller that copes with intermittent use can fail under continuous work. The transfer did not cause the weakness; it was the first operation to require the card to sustain effort.
Why the four-hundred mark is worth noting: it says roughly how far into the card the reading got. Files are generally transferred in order, so the failure point corresponds approximately to a position on the card rather than to a time.
What that implies about the boundary: the first four hundred read successfully. Those are already on her computer and are not part of the problem, and the outstanding set is the remainder — a defined quantity rather than an unknown one.
Why the card failing in the camera too is expected: the camera has to read the card before it can do anything. Whatever prevents a computer reading it prevents a camera reading it — one fault seen in two places.
Why that is nonetheless the useful confirmation: a card readable in the camera but not the computer would point at a reader or a connection. Failing in both places puts the fault in the card, and she established that herself.
Why the images are very likely intact: they were written during ordinary shooting, when the card was working, and verified at the time. A controller failing during a later read does not alter what was stored — the memory holds what went onto it.
Why two formats helps rather than complicates: raw and compressed images have different recognisable openings. Each is located independently by signature, and where one format proves harder the other frequently recovers cleanly.
Why the partial upload should be preserved carefully: those four hundred are already safe. They should be copied somewhere else before anything else is done, so that whatever happens next cannot affect them.
What must not happen: no reinserting into the camera, no further transfer attempts, and no formatting if any device offers. Each attempt asks a failing controller to repeat the work that defeated it.
On the bench
Failure during transfer was treated as sustained-read stress rather than transfer error — shooting writing in bursts and touching small areas, whereas an upload reads every occupied region continuously and at speed, the heaviest sustained demand a card receives, so a controller coping with intermittent use can fail under it. Files transferring in order means the failure point corresponds to a position on the card. Memory was read past the controller, with raw and compressed images carved separately.
The outcome
The failure treated as sustained-read stress, the card removed from use and addressed through hardware, and both image formats carved separately. Free assessment, one fixed written figure including VAT; on cards where content has been deleted or overwritten, the figure is payable upfront. The decode: the upload found the fault rather than causing it. Shooting touches small areas in bursts; an upload reads the whole card continuously — and your images were written when the card was working.
A card that fails partway through an upload
Copy the images that did transfer somewhere else first, since those are already safe and nothing that happens next should be able to affect them. Then stop — no reinserting into the camera, no further transfer attempts, no formatting. Understand why it failed when it did: shooting writes in bursts and touches small areas, while an upload reads every occupied region continuously at speed, which is the heaviest sustained demand a card ever gets. The transfer surfaced a weakness rather than creating one, and your images were written when the card was working normally.
Secure what came across, then stop — call Manchester Data Recovery on 0161 871 0788; failure treated as sustained-read stress, addressed through hardware with imposed timeouts, memory read 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.