Call us — 01483 901310
Mon–Fri · 9am–5:30pm · No fix, no fee
Start a free diagnostic →

Data Recovery Case File · Cameras, Drones & Cards · The Same Point Every Time

A Consistent Stopping Place Is a Location

His enquiry contains a detail that most people report as frustration and which is actually a measurement. A card that died mid-copy: "the card is now unreadable on Windows or Mac, however recovery tools do see the drive and give the impression that files are still there — however it fails at around 90% of scanning the card." He is filming today and needs an answer. Failing at the same proportion every time is not a flaw in the software — it means there is something at a specific physical place on that card, and knowing that changes the approach entirely.

MediaSD card failing during a copy operation — not readable by either host operating system; recovery software enumerating the card and halting consistently at approximately 90% of a scan
Reported situationCard failing while data was being copied from it · not readable on either platform · recovery software able to enumerate the card and list apparent contents · scans halting consistently at approximately 90% · production work in progress
Fault classLocalised unreadable region at a defined offset — full-surface scanning unable to complete; imaging under timeout control indicated
Equipment usedRepeat scanning discontinued · imaged write-blocked under per-block timeouts with the failing region deferred (DeepSpar USB Stabilizer 10Gb) · unreadable extent mapped by offset · recovery performed against the image · media validated by rendering

The decode: what a repeatable stopping point means

Why consistency matters: if a scan failed at a different place each time, that would suggest instability — a controller dropping out, a connection problem, or heat. Failing at the same point on every attempt means the software is reaching a specific region and being unable to get past it. That is a location, not a malfunction, and it converts a vague failure into a mapped one.

Why the scan cannot finish: recovery software reads the whole card looking for file signatures and index remnants. When it meets a region that will not return data, it retries, waits, and eventually either hangs or aborts — because those tools are written for cards that read, not for cards that stall. So the same nine-tenths gets scanned over and over and the last tenth is never reached.

Why the tools listing files is reliable evidence: they got through the first ninety per cent and found real material. Their inability to complete says nothing about the files they already identified — those are present and readable.

What actually happens instead: imaging with a strict time budget per block. Each unreadable region is given a limited number of attempts and then deferred rather than allowed to stall the operation, so the capture continues past it and returns to the difficult area on later passes. The result is a complete image file with a known map of what could not be read — and the recovery software then runs against that image, where every scan completes because an image is an ordinary file with no stalling regions in it.

Why that ordering is the whole trick, and it recurs throughout this archive: you cannot scan a device that will not read all the way through. Capture first with something built to tolerate failure, then scan the copy.

What repeated scanning has already cost: each attempt reads ninety per cent of the card again and then hammers the failing region. On flash media that is less damaging than on a mechanical drive, but it is not free — sustained retries generate heat and the failing area is being hit repeatedly. Further attempts should stop.

The practical note given he is working: the affected region is at a known proportion of the card, which usually means the material written around that point is what is at risk. Everything written earlier — the first ninety per cent, chronologically the earlier footage — is likely to come back complete.

On the bench

Repeat scanning was discontinued, each attempt re-reading the bulk of the card before hammering the same failing region. The card was imaged write-blocked behind the DeepSpar USB Stabilizer 10Gb under per-block timeouts with the failing region deferred — so capture continued past the stall rather than halting at it, which is precisely what consumer scanning tools cannot do. The unreadable extent was mapped by offset, recovery performed against the image, and media validated by rendering.

The outcome

The failing region mapped by offset, the card imaged under timeout control and recovery run against the image. 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 whose scan stops at the same point: that consistency is a finding. Failing at a different place each time would suggest instability; the same place every time means a specific region the software cannot get past. Scanning tools are written for media that reads, so they stall there — capture with something that defers failures, then scan the copy.

Recovery scan that stops at the same point every time

Stop rerunning it — and take that consistency as useful information rather than frustration. Failing at a different place each attempt would suggest something unstable, like a connection or heat problem. Stopping at the same proportion every time means the software is reaching one specific region and can't get past it, so you have a location rather than a mystery. Consumer recovery tools are written for media that reads, so when they meet a region that stalls they retry, hang and abort — which is why the same ninety per cent gets scanned over and over and the rest is never reached. The files it already listed are real and present. What's needed is a capture that defers failing regions instead of halting, and then scanning the copy.

Scan that never gets past the same point?
Stop rerunning it — call Guildford Data Recovery on 01483 901310; imaged under per-block timeouts with the failing region deferred, extent mapped by offset, recovery run against the image.
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.