Data Recovery Case File · Cameras, Drones & Cards · The Number Is a Fallback
A Thousandth of Its Own Size
His enquiry includes a figure that does most of the work. His partner dropped her phone and shortly afterwards the memory card became inaccessible: "I looked into using recovery software but it detected that the 32gb SD card had 32mb of storage, suggesting something else is wrong with it." He is right that it means something else. A card reporting a thousandth of its capacity is not reporting a measurement — it is a device that could not read its own configuration and has fallen back on a minimal default, which is a specific fault with a specific route past it.
| Media | 32GB microSD card from a mobile handset — reporting approximately 32MB of capacity following an impact to the phone; contents inaccessible |
| Reported situation | Handset dropped · card becoming inaccessible shortly afterwards · recovery software reporting the card's capacity as approximately one thousandth of its actual size · contents required |
| Fault class | Controller unable to read its own configuration — default capacity reported; memory readable independently of the controller |
| Equipment used | No further insertion attempts · enumeration and reported geometry read write-blocked under strict timeouts (DeepSpar USB Stabilizer 10Gb) · chip-level read past the controller · translation layer reconstructed in software · media validated by rendering |
The decode: where a card keeps its own size, and what a default means
How a card knows how big it is: not from anything printed on it. Every card holds internal configuration in a reserved area its controller reads on start-up — capacity, geometry, the map of which physical blocks correspond to which addresses, and the tables managing wear. What the card reports to a host comes from there. Reading that configuration is the first thing it does and everything else depends on it.
What a tiny reported capacity means: the controller could not read that configuration and has reported a fallback — a minimal default built into its firmware for exactly this circumstance, so that it can present something rather than nothing. So the 32MB figure is not describing anything on the card; it is the card saying I cannot read my own description. The memory is all still there, entirely untouched, behind a controller that cannot currently address it.
Why the drop is implicated: an impact to a phone reaches the card in two ways. The card can be jolted in its slot, damaging the contacts or the slot's springs. And more relevantly here, the impact can crack a solder joint or an internal connection within the card's own package — cards are small, rigid and soldered, and a sharp shock transmitted through the handset is enough. A controller that has lost a connection to its configuration area produces precisely this behaviour.
Why recovery software cannot help: worth stating because it is the obvious next thing to try. Applications ask the operating system for a device and read what it presents. Presented with 32MB, they will scan 32MB — thoroughly, and to no purpose, because the remaining capacity is not being offered to them at all. Their failure says nothing about whether the data survives, and running more of them achieves nothing.
How it is actually reached: the memory is read directly through the card's internal test points, bypassing the controller entirely. What comes back is raw — scrambled, error-coded, and arranged by the controller's own internal scheme — so it is descrambled, error-corrected and reassembled in software through the translation layer until the filing structures stand up and the images are addressable.
What to stop: further insertion, in the phone or anywhere else. The card should also stay out of the handset that was dropped, since a damaged slot can harm what is inserted.
On the bench
No further insertion was attempted, and the card was kept out of the handset that had been dropped, since a slot damaged by the same impact can harm what is inserted. Enumeration and the reported geometry were read write-blocked under strict timeouts behind the DeepSpar USB Stabilizer 10Gb — confirming that the capacity presented was a firmware fallback rather than a measurement, which is what distinguishes this from a genuinely small or partly erased card. The memory was then read at chip level past the controller and reconstructed in software. Media was validated by rendering.
The outcome
The reported capacity confirmed as a fallback, the memory read past the controller and the images reconstructed and validated. Free assessment, one fixed written figure including VAT, 50% of parts and labour upfront with the balance only on successful recovery. The decode, for anyone whose card reports the wrong size: that number is not a measurement. Cards hold their capacity, geometry and address mapping in an internal configuration area the controller must read on start-up, and one that cannot read it reports a built-in minimal default instead. So your memory is intact behind a controller that cannot address it — and recovery software will scan only what it is offered, which is why more attempts achieve nothing.
Card reporting a fraction of its real size
Stop inserting it, and keep it out of the phone that was dropped in case the slot was damaged too. That capacity figure isn't measuring anything. Every card holds its own configuration — capacity, geometry and the map linking addresses to physical blocks — in a reserved area the controller reads on start-up, and everything else depends on that read succeeding. A card reporting a tiny fraction of its size has failed to read it and fallen back on a minimal default built into its firmware, so it can present something rather than nothing. Your memory is untouched behind it. That also explains why recovery software is useless here: it can only scan what the card offers it, so it'll thoroughly search a few megabytes and find nothing.
That's a fallback, not a measurement — call Newcastle Data Recovery on 0191 406 1051; geometry read under strict timeouts, memory read at chip level past the controller, media validated by rendering.
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.