SD Card Recovery on Windows: File Carving and Media Integrity Checks

When an SD card or microSD card becomes unreadable, whether after accidental deletion, a quick format performed in the camera, or power loss during recording, recoverability depends on both file-system metadata and the state of the underlying logical sectors.

For developers and technical users, understanding where file-system recovery and signature-based carving stop helps avoid secondary damage and false-positive results. Getting valid files back requires knowing how FAT32 and exFAT record deletions, isolating the physical volume from OS writes, and verifying that extracted media actually decodes.

1. File-System Metadata vs. Logical Sectors: Deletion vs. Formatting

Under the SD Association specification, memory cards are formatted FAT32 (SDHC, up to 32GB) or exFAT (SDXC, 64GB and above) by default (see the Microsoft exFAT File System Specification). Deleting individual files and running a format operation affect these volumes differently:

• File Deletion on FAT32 vs. exFAT: On FAT32, deleting a file marks the directory entry as deleted (typically replacing the first byte of the filename with 0xE5) and releases its cluster chain in the File Allocation Table. On exFAT, cluster allocation is tracked through an Allocation Bitmap; because FAT chain entries are often left unzeroed until reclaimed, contiguous files have a high chance of reconstruction, depending on whether directory entries have been reused.
• Quick Format Operations: A quick format is not the same as deleting files. It rebuilds file-system structures (such as boot records, FAT/bitmap regions, and root directories) and may overwrite metadata needed to locate prior file chains. Its exact behavior depends on the host camera, operating system, and formatting implementation.
• Logical Sector Availability: Some file contents may remain readable after deletion or formatting, but preservation is never guaranteed. Recovery software reads the logical sectors exposed by the card controller rather than accessing raw NAND flash cells directly. Recoverability depends on formatting behavior, subsequent writes, controller firmware operations, and media health.

Deleted data does not sit frozen indefinitely. Controller erase and wear-leveling behavior varies across card models, host devices, and firmware revisions, making immediate cessation of card writes the single most decisive factor for recovery.

2. Precautions Before Running a Recovery Scan

Before scanning a memory card on Windows, three precautions reduce the risk of overwriting surviving clusters:

1. Enable the Lock Switch as an Extra Precaution: If using a full-size SD card or microSD adapter with a physical lock switch, slide it to the locked position. This switch is a reader-enforced write-protection signal rather than a physical circuit breaker on the card itself (some inexpensive readers and custom drivers ignore the signal entirely). For forensic or critical files, work from a raw bitstream image made behind a hardware write blocker.
2. Avoid MTP/PTP-Only Device Connections: Connecting a phone, drone, or camera over USB often exposes files via Media Transfer Protocol (MTP) or Picture Transfer Protocol (PTP) rather than exposing the underlying block device. Because recovery software generally cannot scan unallocated space over MTP/PTP, remove the card and insert it into a compatible card reader. The card does not need a Windows drive letter if the recovery tool can access the physical disk device, provided the controller still reports a valid capacity.
3. Never Export Files Back to the Source Card: Always save recovered files and disk images to a separate local SSD or external hard drive. Writing recovered output back to the same SD card will overwrite unallocated clusters still waiting to be scanned.

3. Step-by-Step Recovery Workflow on Windows

In engineering and forensic workflows, the safest initial step is creating a raw sector image (for instance, using ddrescue or a raw disk imager) and scanning that image rather than running repeated read passes across fragile flash memory.

Whether scanning a raw image or the direct physical disk, recovery utilities combine two passes: first reconstructing surviving directory entries and allocation tables, then falling back to signature-based file carving when metadata is destroyed.

Signature-based carving scans unallocated sectors for known file headers and footers. Because it bypasses the file system entirely, carved outputs lose original filenames and folder structures. Non-contiguous (fragmented) files, especially high-bitrate video clips, will often be incomplete or require format-specific cluster reassembly.

To run a structured recovery workflow on Windows 11/10:

1. Connect the Card Reader and Cancel Format Prompts: Insert the card via a compatible reader. If Windows displays a dialog asking to format the drive or run CHKDSK, cancel it immediately so the OS does not modify the volume.
2. Scan the Volume in Read-Only Mode: Use a recovery utility that accesses the storage volume strictly in read-only mode, and always direct exported files to a separate physical drive (a practical example is outlined in the iFinD SD card recovery guide for Windows, where iFinD Data Recovery parses remaining metadata and signatures on FAT32 and exFAT volumes). Note that read-only access does not eliminate hardware risks on an unstable card: if the device drops off the bus, throws repeated I/O errors, or overheats, stop immediately to avoid degrading the controller.
3. Filter by File Type and Preview Candidates: Filter the scan results by file extension or media category (such as JPEG, PNG, Canon .CR3, Sony .ARW, or MP4/MOV) to separate target media from cached thumbnails.
4. Export Selected Files to Separate Storage: Select the recovered files and export them to a local workstation folder for integrity testing.

4. How to Verify That Recovered Photos and Videos Are Intact

A file appearing in a recovery list (or even displaying a valid thumbnail) does not prove the full payload was recovered. Embedded EXIF thumbnails live in the first few kilobytes of a photo, meaning a file can preview normally in a thumbnail grid while the main image stream is truncated or filled with unrelated sectors.

Reliable verification separates checks into three levels:

1. Structural Check: Does the file container conform to expected format headers and footers?
2. Full Stream Decoding: Can an image or media decoder read every frame/pixel from start to finish without stream errors?
3. Original Hash Comparison: When pre-loss checksums (SHA-256 or MD5) or backup copies exist, do the byte streams match? Without an original baseline, passing structural and decode checks indicates the file is readable, though visual and playback review is still required.

Checking JPEG and Raster Images with Python (Pillow)

JPEG Start of Image (0xFFD8) and End of Image (0xFFD9) markers are useful structural clues, but they do not guarantee a photo is intact; a carved file can contain both boundary markers while harboring corrupted scanlines or mismatched cluster fragments in the body. Similarly, according to the Pillow Image.verify() documentation, calling verify() only checks structural headers without decoding the actual pixel data.

To test both structural headers and full pixel decoding across a folder of recovered raster images, install Pillow first:

python -m pip install Pillow

Then run the following two-stage verification script on your exported folder (note that camera RAW formats such as .CR3, .NEF, and .ARW require dedicated RAW decoders like rawpy or LibRaw and are outside the scope of this script):

from pathlib import Path
from PIL import Image

recovered_dir = Path(r"D:\Recovered_Photos")
extensions = {".jpg", ".jpeg", ".png", ".tif", ".tiff"}

if not recovered_dir.is_dir():
    raise SystemExit(f"Directory not found: {recovered_dir}")

for path in recovered_dir.rglob("*"):
    if not path.is_file() or path.suffix.lower() not in extensions:
        continue
    try:
        # Stage 1: Structural check; does not fully decode image pixels.
        with Image.open(path) as image:
            image.verify()

        # Stage 2: Reopen after verify() and decode every frame/page.
        with Image.open(path) as image:
            for frame in range(getattr(image, "n_frames", 1)):
                image.seek(frame)
                image.load()
                image.tobytes()  # Forces full raster decompression

        print(f"[CHECKS PASSED --- visual review still needed] {path}")
    except Exception as exc:
        # Failures may indicate truncation/corruption, unsupported codecs, or permission issues.
        print(f"[REVIEW REQUIRED] {path}: {exc}")

Treat [REVIEW REQUIRED] entries as files needing manual inspection, and still visually spot-check files that pass automated decoding to confirm there are no shifted color blocks or spliced sectors.

Checking Recovered MP4 and MOV Video Streams with FFmpeg

MP4 and MOV containers rely on metadata boxes (such as moov) to index video and audio tracks. Depending on the recording device and whether fragmented MP4 is used, these structures can sit at the start or end of a file. Interrupted recordings, fragmented clusters, or file-system damage can leave metadata incomplete or media payloads (mdat) truncated.

Rather than relying on a quick timeline scrub in a media player, you can run FFmpeg on the exported video copy to decode the entire video and audio stream to a null sink and flag stream errors:

ffmpeg -v error -xerror -i "D:\Recovered_Videos\clip.mp4" -map "0:v?" -map "0:a?" -f null -

Note that -xerror terminates on the first decoding anomaly; omit this flag if you want to inspect a full log of non-fatal stream errors.

Always execute decode commands on an exported copy residing on your local drive rather than reading directly from the source SD card. Doing so keeps the source media idle for further extraction and protects against mid-decode device dropouts on unstable cards. While a zero exit code confirms the audio and video streams decoded without fatal container errors, you should still spot-check overall runtime, visual sync, and audio clarity.

5. When Software Recovery Is Unlikely or Not Possible

Software recovery tools operate through the storage controller and have hard boundaries:

• Overwritten or Erased Data: Data that has genuinely been overwritten by new recordings (such as continuous dashcam loop recording) or cleared by controller-level erase commands and is no longer accessible through the controller cannot be reconstructed by recovery software.
• Controller or Hardware Failure: If an SD card reports an incorrect capacity (such as 0 MB or RAW with I/O timeouts), repeatedly disconnects, or cannot be detected in a known-good compatible card reader, ordinary software cannot read its sectors. In these cases, stop powering the card and consult a specialist flash-recovery laboratory, though even chip-level recovery depends on the card's packaging and controller encryption and does not guarantee success.

Summary

Successful memory card recovery requires a disciplined three-step sequence: isolate the card from operating-system writes immediately, run non-destructive extraction (ideally from a sector image), and test the decodability of exported streams rather than relying on thumbnail previews. Treat automated checks as filters rather than final verdicts, and verify playback and image raster data before putting restored files back into production.