microSD Corruption and How It Happens

The failure that loses everything at once is usually a card that was never the size it claimed. Writes succeed until they pass the end of the real storage, wrap round, and overwrite what went on first — so it works perfectly right up to the moment almost nothing does.

The second most common cause is not wear either. It is the index being updated when power or the card goes away.

A note on this guide: this rests on how flash storage and its filesystems behave rather than on cards failed deliberately here. See how we test.

The problem, as it appears

The card has been fine. Games installed, saves worked, nothing unusual — and then a title will not launch, several files are unreadable, and the device offers to format it.

Nothing obviously happened in between, which is what makes it feel arbitrary.

Why "cards just fail" disappoints

Because it stops the investigation at the least useful answer, and because wear is rarely what happened.

Flash does wear out, and the number of erase cycles involved is large enough that a card holding a game library — written once, read many times — is nowhere near it. Reads cost essentially nothing. A card that failed after a few months of normal use failed for a different reason.

The two that account for most of it are both avoidable, and neither is about quality in the way people mean it.

What actually matters

Capacity that was never there

The single most common cause of a card that dies all at once.

A card can be made to report a capacity far larger than the flash inside it. Writes below the real size work perfectly. Writes past it wrap round to the beginning and overwrite what was already there — so the card behaves impeccably while you are filling the first part of it, and then destroys that part without warning.

The signature is exactly the one people describe: weeks of normal use, then widespread loss in one event.

The defence is to verify rather than to trust. Write real data across the whole card and read it back, comparing what comes off against what went on. Free tools do this on every platform, and it takes minutes for a card you are going to rely on.

Checking free space proves nothing — a card that lies about capacity lies about free space with equal confidence.

This page contains affiliate links. If you buy through them, Ugly Fixes may earn a commission at no extra cost to you. Products are selected independently.

Which specification actually decides handheld performance is covered in handheld storage: microSD cards and what to buy.

The index is the fragile part, not the file

Pulling a card out or losing power during a write is the second big cause, and the damage is usually not where people expect.

Saving a file also updates the structure recording where everything on the card lives. Interrupt that update and the structure can be left inconsistent — which makes files you were not touching unreachable, even though the data is still physically present.

That is the mechanism behind the card that appears empty, or that lists files which will not open. The filesystems used on large cards keep no journal, so there is nothing to replay on the next mount.

Practically: eject rather than pull, and be careful around sleep and wake on a handheld, which is where a card gets removed while the device still believes it has it.

Heat is a slow contributor

Sustained heat is unkind to flash and to the small controller managing it, and a handheld under load is a warm enclosure with a card inside it.

This is a shortening rather than a cause — it does not produce a sudden failure, and it is one reason the same card lasts longer in a reader on a desk than in a device that runs hot for hours.

What actually cools a handheld, and what merely appears to, is in do clip-on handheld coolers work.

Leave the card some room

The controller spreads writes across cells so that no small region takes all the wear. It needs unused space to do that.

A card kept permanently at its absolute limit gives it very little to work with, which concentrates writes rather than distributing them. Leaving some headroom is free and it is the kind of habit that only shows its value in its absence.

Format in the device that will use it

A card formatted by the device gets the parameters that device expects. A card formatted elsewhere with different settings can work and be slower, or behave oddly in ways that get attributed to the card.

It costs nothing to do it the right way round, and it removes a variable from any later investigation.

When it starts to fail, stop writing

The instinct is to run a recovery tool immediately. The better first move is to stop.

Make a complete image of the card onto a real drive, then work on the image. Recovery software that writes to a card which is already failing can overwrite the data being recovered, and a card behaving unpredictably may not survive the process.

And treat a card that has thrown one error as untrustworthy afterwards. It may run for another year; it has also told you something.

The saves are the part that matters

Games can be downloaded again. Progress, screenshots and configuration cannot, and they are the smallest files on the card.

That asymmetry makes the sensible arrangement obvious: copy the small irreplaceable things somewhere else regularly, and stop worrying about the large replaceable ones.

Which files actually need protecting is set out in backing up more than game saves, and why redundancy on one machine is not the same thing is in RAID is not a backup.

The order to work in

1. Verify capacity on any new card before trusting it.
2. Format it in the device that will use it.
3. Leave headroom rather than filling it to the limit.
4. Eject properly, and mind sleep and wake.
5. Copy the saves off on a schedule you will actually keep.
6. On the first error, stop writing and image the card.
7. Retire it afterwards, whatever it does next.

The mistake to avoid

Trusting a capacity because the device reported it. A card that misreports its size reports it to your computer, your handheld and your camera with the same confidence, so every check short of writing and reading back real data agrees with the label. The failure is silent by design, it destroys the oldest data first, and the few minutes of verification is the only thing that catches it before several months of use are lost.

The second mistake is running recovery software directly against a card that is already misbehaving. It writes while it works, on a device that has just demonstrated it cannot be relied on to write — which is how a partially recoverable card becomes an unrecoverable one. Image first, then do whatever you like to the copy.