CFexpress Card Recovery: Also CFast, XQD and CF Cards

Updated by XAppSet Team

CFexpress card recovery starts with a question that does not apply to SD cards: did the footage ever reach the card? Professional media sit behind their own controller, and the interface is fast enough that the bottleneck has moved to the camera’s buffer. A clip still draining from the buffer when the card was pulled, or when the battery was swapped, never existed as a complete file — and no recovery tool can find a file that was never written.

Answer that question first, then work the detection order. The rest of this page covers how the four professional formats differ underneath, what that difference means for recovery, and the sequence to follow when a card holding a day’s work does not appear in a computer.

The Four Professional Formats, and Why Each Behaves Differently

Four professional card formats laid out with their distinct physical shapes

The formats that replaced SD on high-end bodies are not variations of one design. They use different buses and different command sets, which is why recovery advice does not transfer cleanly between them.

FormatInterfaceCommand setTypical sizeRemoval risk
CFexpress Type APCIe 3.0 x1 (Gen 4 on newer bodies)NVMe80 GB – 1 TBHigh; Deallocate is available
CFexpress Type BPCIe 3.0 x2 (Gen 4 on newer bodies)NVMe128 GB – 4 TBHigh; Deallocate is available
CFast 2.0SATA IIIATA128 GB – 1 TBMedium; TRIM may be issued
XQDPCIe 2.0 x2, proprietary protocolVendor-specific64 – 240 GBLow; no standard trim command
CompactFlashParallel ATA (PATA)ATA32 – 256 GBLow; no trim command in the original standard

Two rows explain most real-world outcomes. CompactFlash and XQD are the forgiving end: neither exposes a standard mechanism for a host to tell the card that data is no longer needed, so a file deleted or a volume reformatted on those media tends to remain physically present until new writes claim the space. CFexpress is the unforgiving end, for reasons covered below.

Card size is a practical factor too. A 4 TB CFexpress Type B holds a great deal of footage, and a full block-level scan of a volume that large takes hours rather than minutes — worth knowing before you start a scan at midnight before a delivery. The broader landscape of card types and interfaces is covered in the range of camera memory card types.

What CFexpress Actually Is: NVMe Inside a Camera Card

CFexpress is an NVMe solid-state drive with a different connector. That sentence explains nearly every behavioral difference between it and an SD card.

NVMe is the protocol developed for PCIe-attached SSDs, and it brings the whole SSD feature set with it: multiple queues, deep command pipelines, and a set of management commands that includes Deallocate, the NVMe equivalent of SATA’s TRIM. When a host issues Deallocate for a region of the card, it is telling the card’s controller that those logical addresses no longer hold live data, and the controller is then free to reclaim the underlying flash at any time, without further involvement from the host.

The consequence is counterintuitive. The same deletion is less dangerous on an old CompactFlash card than on a modern CFexpress card, because the old card has no mechanism to act on the news. On CFexpress, a delete followed by a period of idle time on a system that issues Deallocate can put the data genuinely beyond reach, with no write from you involved. The file system view never changes — the file simply stops being findable at the flash level. This is the same dynamic that makes an SSD a worse recovery target than an SD card, and it is why the standard advice to power down and stop touching the card carries extra weight here.

The Controller and Its Translation Table

The card controller and its translation table mapping logical files to physical blocks

Every flash card presents a simplified view of itself to the host. The physical flash must be erased before it can be rewritten, while the host sees a numbered sequence of logical addresses it can write freely. The layer that reconciles the two is the flash translation layer (FTL), run by the card’s own controller.

On a professional card that layer is larger, more granular, and more proprietary than on an SD card. Three effects follow.

The computer never sees the flash. Software recovery works at the logical level: it reads what the card’s controller exposes as a block device. If the controller has decided a logical address maps to a reclaimed block, no tool can read around that decision. Bypassing it is a laboratory technique involving direct access to the bare flash.

Mapping granularity affects carving. A larger FTL with finer mapping means a reformatted card’s free space may be redistributed in smaller units, so recovered files return in more scattered order and with more gaps.

A failed controller is not a software problem. Because the controller sits between host and flash, a card whose controller has died cannot be enumerated at all. It is not a corrupted volume waiting for a scan; it is an unreadable device. The criteria for that decision are set out in when data recovery software is not enough.

Some Professional Cards Encrypt by Default

A subset of professional media implement hardware encryption in the controller, either as a security feature or as a side effect of a secure-erase implementation. Encryption is transparent while the card is used in a device that holds the key material, and that is what makes it a recovery problem.

If the controller loses or regenerates the key material — after a firmware fault, a secure-erase interrupt, or certain failures — the data on the flash is cryptographically unreadable even if every byte is intact. Software cannot recover a key it has no path to, and the constraint is absolute rather than a matter of tooling quality.

The practical implication is simple: never run a card’s secure-erase or format-with-erase routine on a card holding anything you might need, and treat any menu item containing the word “secure” as a fully destructive format.

First Question: Did the Clip Actually Land?

Before any troubleshooting, establish whether the missing file was ever fully written.

Professional bodies buffer several seconds of high-bitrate footage in memory and drain it to the card after recording stops, sometimes for five to ten seconds. Many also write the clip’s metadata index — the container structure describing frame positions — at the end of the file rather than continuously. Both behaviors create a window after the REC indicator goes out during which pulling the card, removing the battery, or cutting power loses the clip or leaves it without an index.

Ask what happened immediately before the loss:

  • Card removed within a few seconds of stopping recording. Treat it as an incomplete write. The file, or a partial version, may be present and repairable even if it will not play.
  • Battery pulled, camera powered off, or a crash during recording. The clip was cut off mid-file. The recorded frames are usually present; the index is not.
  • Camera reported “Unable to access card” but the shoot continued. The camera recognized the interface, not the volume. Check for a file system problem rather than a hardware one, since the interface is working — the split described in corrupted SD card recovery.

An incomplete recording is one of the better outcomes in this list. A video file that exists but will not play is frequently whole at the data level: the frame data is present and only the container index is missing, which is repairable — see repairing video files with a missing index. What is genuinely unrecoverable is a file whose data blocks were never written, and the timing above identifies that case. For cinema formats the container work is more involved, since RAW formats carry their own indexing and frame tables; that branch is handled in cinema camera and RAW video recovery.

When the Card Is Not Detected: A Fixed Order

Work through these steps in order, and stop when the card appears. Repeating steps out of order is how a marginal card gets worse.

StepActionWhat a failure tells you
1Use a reader designed for the format, on a port that supports itA CFexpress Type B card will not enumerate on many USB 3.0 readers or hubs
2Try a second, known-good cable and a direct portEliminates the cable and the hub as variables
3Try a different computer and operating systemSeparates a driver or OS issue from a card issue
4Check whether the card appears without a volume letterIf it enumerates with no file system, the controller works and the volume does not
5Let the card reach room temperature if it is very cold or very warmSome controllers refuse to initialize outside a temperature window
6Stop and get professional assessmentIf it never enumerates, the problem is hardware

Step one deserves emphasis because it is where most “dead card” reports originate. CFexpress Type B requires a reader that supports PCIe tunneling with adequate power delivery. A reader that works perfectly for SD cards may not enumerate a CFexpress card at all, or may enumerate it and drop it during the first sustained read. The card, the reader, and the port are three separate failure candidates, and the decision path that separates them is laid out in the card not detected decision tree.

If the card enumerates as a volume but the volume is unreadable, do not accept a format prompt. That prompt describes the file system, not the data, and accepting it on a card with a merely corrupted index removes the directory entries that would have preserved your file names.

What Recovery on a Professional Card Looks Like

If the card mounts, or appears without a usable volume, and the loss was logical — deleted files, a reformat, an interrupted recording — a scan is worth running. On large CFexpress media the scan itself is the long part: a 2 TB card read at 500 MB/s takes over an hour just to traverse once.

If you are on Windows and the card is still detected by a computer, a purpose-built recovery tool such as XRecovery (xappset.com) can scan SD, microSD, and other memory cards for deleted or formatted photos and videos. As with any recovery tool, stop writing to the card first and always save recovered files to a different drive. On professional media the outcome splits sharply by cause: a card reformatted and then left alone usually yields its footage, while a card reformatted and used again for another shoot may return only the clips stored in blocks that were not reused, because the controller has no obligation to preserve what it has already reclaimed. Where the loss is physical — a cracked shell, a bent connector, a card that has been through water — software has no role, and the situation is the one described in physically broken card emergencies. Understanding which category you are in before spending money is worth ten minutes, and the boundary is drawn in what to do when data is unrecoverable.

Frequently Asked Questions

Why is my CFexpress card not detected by my computer?

The reader is the most common cause. CFexpress Type B needs a reader that supports PCIe tunneling and delivers sufficient power; many USB 3.0 readers and unpowered hubs will not enumerate it reliably. Try a format-appropriate reader on a direct port, then a different computer, before concluding the card has failed.

Can deleted files be recovered from a CFexpress card?

Sometimes, and with less margin than on an SD card. CFexpress uses NVMe, which includes a Deallocate command that lets the host mark addresses as free so the controller can reclaim the flash in the background. If the card has been deleted from and then left idle on a system that issues that command, the data may already be gone.

Is a reformatted CFexpress card recoverable?

Usually yes, if the card has not been used since. A reformat rebuilds the file system while leaving recorded data in place, so a raw scan can find it. If the card has since recorded another shoot, the survivors are those in blocks the controller has not reused.

Does a professional card encrypt its data?

Some do. Certain professional media implement hardware encryption in the controller, either for security or as part of a secure-erase feature. While the card is used normally the encryption is invisible; if the controller loses its key material, the data cannot be read by any tool.

Privacy Overview
XAppSet

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful. Learn more

Strictly Necessary Cookies

Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.