When a camera corrupts memory card after memory card, the reflex is to buy another card. That reflex is wrong often enough to be expensive. The same firmware that writes a bad directory entry, misjudges a card’s bus speed, or loses power before flushing a buffer will damage a new card just as quickly as it damaged the first one, and better media will not fix a camera-side fault.
The way out is a cross test, and it takes two swaps: put the suspect card in a second camera, and put a known-good card in the suspect camera. Whichever component carries the failure across both swaps is the one at fault. It costs nothing and settles most cases in under an hour.
Blaming the card is the default mistake
Cards fail loudly or quietly. A loud failure is a card the camera will not mount at all. A quiet failure is a card that mounts, accepts writes, and then produces files that will not open or video that freezes a few seconds in. Camera firmware fails in exactly the same two shapes, which is why the two get confused.
Three things keep the confusion alive. Replacing the card usually appears to work, because a fresh card has clean free space and survives a few sessions before the underlying fault surfaces again. Counterfeit cards produce symptoms indistinguishable from firmware bugs, so buying a more expensive card sometimes fixes things for reasons unrelated to firmware. And firmware faults are often load-dependent: a body that only fails at 4K 120 fps, or only after the buffer has been filling for forty seconds, will pass every casual test in a store.
The two-swap cross test
Run the test with the workload that actually fails, not a convenient one. A camera that survives twenty JPEGs at 8 MB/s has told you nothing about a write pipeline that fails at 200 MB/s.
Swap one: the suspect card in a second camera. Do not format it first. Shoot enough material to reproduce the failure, then read the card with a reader and a computer rather than through the camera’s USB port. Confirm that every file opens and plays to the end.
Swap two: a known-good card in the suspect camera. Use a card you have verified with a write-and-read test, from a different batch or brand. Match the settings, the clip length, and the ambient temperature of the original failure.
| Outcome | Reading | Next move |
|---|---|---|
| Fails in both cameras | Card-side fault: wear, a counterfeit controller, or physical damage | Retire the card; test any spares the same way |
| Passes in the second camera only | Camera-side fault: firmware, slot contacts, or power delivery | Stop shooting on that body and pursue a firmware fix |
| Fails in every camera and every reader | Physical or controller failure | Recovery software will not help; see the options below |
| Passes everywhere until the card is nearly full | File system or allocation handling on the camera side | Back up sooner and cap the card’s fill level |
One caution about method: if you format the card between swaps, you destroy the evidence you were trying to gather and may destroy recoverable files. Test with the card as it is.
What the camera’s write path actually does to a card
A camera writing a file is running four layers, and a bug in any of them presents as “the card corrupted.”
The application layer decides file names, folders, and chapter boundaries, and enforces the DCF (Design rule for Camera File system) conventions that keep a card readable across brands.
The file system driver maintains FAT32 or exFAT structures. This is where the largest single risk hides, because a file is not one object on the card. The directory entry, the allocation table, and the file’s data are three separate writes, and the camera does not commit them atomically.
The card interface driver speaks the SD or CFexpress protocol. It negotiates a bus speed, issues multi-block writes, and is responsible for respecting the card’s busy signal and handling CRC errors. Firmware that optimizes away a busy check produces files that look complete and are not.
The physical layer is the slot itself: contacts, a detect switch, and the power rail. A tired slot with one oxidized contact behaves like a firmware bug for months, because it fails only when the card shifts slightly.
Two consequences of that architecture explain most of the confusing cases.
The first is that a card which never fails in an older camera can fail on the first shot in a newer one. Bodies negotiate bus speed with the card, from 12.5 MB/s at default speed up to 104 MB/s or more on UHS-I and higher still on CFexpress. A marginal card does not degrade gradually; it works until the clock rate rises, then fails. That is why “the card is fine, I used it for years” and “this camera eats cards” can both be true.
The second is that the camera can leave a card looking healthy while a file on it is a stub. The file system is intact, the folder listing is normal, the file has a plausible size, and the clusters behind it were never written. The camera committed the directory structure and then lost power or hit a bug before committing the payload. No error is ever reported.
Firmware failure patterns you can recognize
| Pattern | What the user sees | Where it originates |
|---|---|---|
| Missed flush before power-down | A clip that plays two seconds and freezes | Application layer, index never committed |
| Bus speed overreach | Works in one body, fails in another, same card | Interface driver negotiation |
| Capacity or cluster-size misreport | Card works until about half full, then corrupts | File system driver on large exFAT volumes |
| Chapter boundary collision | One chapter missing, its neighbors unplayable | Chaptering logic at the 4 GB rollover |
| File count wraparound | New files replace older ones with the same name | DCF folder and counter handling |
| Stale partial files | Camera refuses to mount a card it wrote itself | Cleanup logic after an interrupted recording |
| Write during voltage sag | Failures cluster at the end of a battery | Power management, not the card |
| Slot contact intermittency | Failures correlate with handling, not duration | Hardware, though it presents as firmware |
If your symptom sits in the top half of that table, the card is probably innocent and the fix is a firmware update or a service visit rather than another purchase. If it sits at the bottom, clean the slot and inspect the contacts first.
Firmware updates are the one place the camera itself is the casualty
Flashing firmware writes to the camera’s own non-volatile storage, and an interruption there is a different class of problem. The risk is not uniform across the update: copying the firmware to the card is harmless if it fails, while erasing and programming the firmware region is not. Most bootloaders verify a checksum and switch images only once it validates, which is why a corrupted download usually aborts rather than destroying the camera. The dangerous window is narrower than people assume but real. The firmware update safety guide covers the preparation that shrinks it and the recovery ladder for a failed flash.
A related surprise: some updates rebuild the card’s directory structure on first boot. Photographers report photos that vanish from the card after an update when the files are still on the media and only the visible index has changed. That is a recovery problem, not a data loss, and formatting at that point turns a solvable problem into a permanent one.
What the cross test cannot tell you
The test isolates which side of the interface is failing, not why.
- Counterfeit capacity. A fake card reports more space than its NAND holds and overwrites its own earlier files once writes pass the real limit, passing short tests in both cameras. The guide to counterfeit cards explains the fill-and-verify test that exposes them.
- Wear. The end of a card’s useful life arrives as a rising error rate rather than a single event, so a worn card can pass one week and fail the next.
- Model-specific incompatibility. A particular card and a particular body can disagree about timing in ways no amount of swapping explains, because the failure needs that exact pair.
Protect the files before you spend time on diagnosis
Everything above is about identifying the culprit. None of it should happen on your only copy of anything.
Stop writing to the card as soon as a failure appears. Move it to a reader and take a full sector-level image before you run any scan, so that every later experiment reads the image instead of the card; the card imaging workflow explains why a damaged card should be read as few times as possible. Diagnose using spare cards only, and delete nothing.
For the recovery itself, if you are on Windows and the card is still detected by a computer, a purpose-built tool such as XRecovery (xappset.com) can scan SD, microSD, and other memory cards for deleted or formatted photos and videos, and it can re-encode recovered clips that will not open. The boundaries apply to every tool without exception: data that has not been overwritten can be recovered in full, a clip that recovers but will not play can usually be made playable by re-encoding what was recovered, and data that has already been overwritten is gone. Stop writing to the card first and save whatever comes back to a different drive.
Frequently Asked Questions
If the card works in my computer, does that clear it?
No. A reader is a different host with a different clock speed and a much lighter write load, so a card that fails at 200 MB/s in a camera can read flawlessly at 20 MB/s in a reader. A clean read proves the data that is there is intact, not that the card accepts sustained writes.
Can a camera permanently damage a card?
It can leave the file system in a state the camera cannot rebuild after repeated interrupted writes, and it can accelerate wear by writing inefficiently. The NAND itself is rarely destroyed, which is why the files are usually still recoverable after the camera has been repaired.
Should I format the card in the camera that corrupted it?
Not before you have recovered what is on it. Format in the camera once the files are off, because that is the format the body expects, but treat a second failure after a clean in-camera format as confirmation that the fault is on the camera side.