CRC Error (Cyclic Redundancy Check)

CRC stands for Cyclic Redundancy Check. It’s a mathematical algorithm that takes a block of data and produces a fixed-length checksum (typically 16, 32, or 64 bits). The storage system computes the checksum when data is written, stores it alongside the data, then re-computes the checksum on every read and compares the two values. If the recomputed checksum matches the stored one, the data is intact; if it doesn’t match, something has changed between write and read, and the storage system reports a CRC error.¹

The mathematical operation

CRC works by treating the data as a long binary number and dividing it by a fixed binary number (the “generator polynomial”). The remainder of that division is the CRC value. The interesting property: small changes in the input data produce dramatically different CRC values, which makes the algorithm excellent at detecting accidental changes (bit flips, single-byte corruption, burst errors). CRC is not designed to detect intentional tampering; an attacker who knows the algorithm can deliberately modify both data and CRC to match. Cryptographic hashes (SHA-256, MD5) handle that case. CRC handles the much more common case of detecting accidental corruption from hardware faults, electrical noise, or aging media.²

CRC variants in storage and networking

The number after CRC indicates the length of the resulting checksum. Common variants:

For storage and recovery purposes, CRC-32 is the variant you’ll encounter most often. It’s what NTFS, FAT32, and exFAT use; it’s what ZIP archives use; it’s what Ethernet frames use. From a user perspective, the variant doesn’t matter; a CRC error means the same thing regardless of which variant detected it: the data doesn’t match its stored checksum.

CRC vs other integrity checks

CRC is one of several integrity-checking techniques used in computing. The others appear in different contexts:

• Parity bits. The simplest form of error detection; adds a single bit to make the total number of 1-bits in a byte either even or odd. Used in RAM and older protocols. Detects single-bit errors but not most multi-bit errors.
• CRC. Detects almost all single-bit and multi-bit errors with very low false-negative probability for the data sizes typical in storage (4 KB to 1 MB blocks). Standard in storage and networking.
• Cryptographic hashes (MD5, SHA-256). Detect both accidental and intentional changes. Used for security verification and torrent integrity. Slower than CRC but resistant to deliberate tampering.
• ECC (Error-Correcting Codes). Don’t just detect errors; they can correct some errors. Used in RAM (ECC memory), NAND flash (BCH codes), and CDs/DVDs. SSDs rely heavily on ECC because raw NAND has high error rates.

CRC errors surface in several specific scenarios. Each implies something different about the underlying problem.³

The Windows error code 0x80070017

The most common user-facing form of a CRC error on Windows is the dialog showing 0x80070017 with the message “Data error (cyclic redundancy check)” or “The data is invalid.” The error code is structured: 8007 indicates a Windows system error (0x80070000 base) and 0017 is the specific code (decimal 23, which is ERROR_CRC). The error appears any time Windows tries to read a sector and the read fails with a CRC mismatch from the underlying storage driver.

CRC errors during file copy: the most common scenario

A user is copying files from one drive to another and the copy stops partway with the CRC error dialog. This is almost always caused by a bad sector under the specific file being read; the file system reads through the file, hits a sector that returns a CRC mismatch from the drive, and reports the error to the OS. The remedy is not to retry the copy (each retry stresses the failing area further) but to image the drive and recover the file from the image with bad-sector-tolerant techniques. If file system metadata regions get hit by CRC errors, the partition can deteriorate to RAW status where Windows can’t recognize the file system at all; recovery in that scenario shifts to file carving from the image.

CRC errors in archive extraction: archive vs drive

When a ZIP, RAR, or 7Z archive extraction fails with “CRC failed,” the question is whether the archive itself was corrupted at creation/transfer or whether the drive is corrupting the archive on read. To distinguish: copy the archive file to a different drive and try extracting it there. If extraction succeeds, the original drive is the problem. If extraction still fails, the archive was corrupted before it reached your drive (bad download, faulty transfer). Most archive formats include their own internal CRC for each file, separate from the file system’s CRC, so an archive can be intact on disk but contain internal corruption.

CRC errors can come from causes that are temporary and trivial to fix, or causes that indicate serious hardware degradation. Distinguishing between them is important for choosing the right response.⁴

Cable and connection issues (often temporary)

A loose SATA cable, a marginal USB connection, or electrical interference can corrupt data in transit between the drive and the computer. The drive is fine; the connection is the problem. Diagnosis: try the drive in a different USB port, with a different cable, on a different computer. If errors disappear, the original cable or port was at fault. This category includes:

• Loose or damaged SATA cables (most common with internal drives)
• Marginal USB-C or USB 3.0 cables (especially with external external hard drives)
• USB hubs with insufficient power for spinning drives
• Electrical interference from nearby high-current devices
• Bad USB ports on the host computer

Bad sectors (the common drive-level cause)

The most common drive-level cause of CRC errors. When the magnetic surface of an HDD develops a defect (or the flash cells in an SSD start to degrade), reads from those locations fail their CRC check. The drive’s controller reports the failure to the OS, which surfaces it as the CRC error dialog. A few isolated bad sectors are common in aging drives and don’t necessarily indicate imminent failure, but a growing bad sector count does. Check SMART data with smartctl or CrystalDiskInfo to see whether the bad sector count is stable or rising.⁵

Drive controller or firmware issues

Sometimes the drive’s surface is fine but the controller chip on the drive’s PCB is failing or its firmware has a bug that causes CRC errors during certain access patterns. The specific Crucial M500 SSD and a handful of other models have documented firmware issues where CRC errors appear without underlying surface damage. Firmware updates from the drive manufacturer sometimes resolve these issues; if not, the only remedy is replacing the drive.

Power supply issues

Insufficient or unstable power to the drive can cause sporadic read failures that surface as CRC errors. This is most common with:

• External 3.5-inch HDDs in cases with marginal power adapters
• USB-powered 2.5-inch drives drawing more current than the USB port supplies
• Internal drives in systems with aging power supply units (PSUs)
• USB flash drives in low-quality USB hubs

RAM corruption (rare but real)

Defective RAM can corrupt data during the read path before it reaches the application. Windows typically catches most cases (Windows 10/11 includes Windows Memory Diagnostic for testing), but undetected RAM errors can produce sporadic CRC errors that look drive-related but actually originate in memory. Run Memory Diagnostic if you’ve ruled out cables and the drive’s SMART data looks clean.

Network and transmission errors

For CRC errors during network file transfers, the cause is in the network path rather than the drive: bad Ethernet cable, faulty switch port, NIC driver issue, or congestion-related packet corruption. These errors typically don’t indicate any storage problem at all; the data is reading correctly from disk but getting corrupted between the source and destination machines.

The recovery workflow for a drive throwing CRC errors follows the same general pattern as the bad sectors workflow, because bad sectors are the most common drive-level cause.⁶

Step 1: Rule out cable and connection issues first

Before assuming drive failure, eliminate the easy causes:

• Try a different cable (SATA or USB) of the same type.
• Try a different port on the host computer.
• Try the drive on a different computer if possible.
• Restart the computer and try the operation again.

If errors persist across these changes, the drive itself is the source of the problem and recovery becomes the priority over diagnosis.

Step 2: Check SMART data

Before imaging or recovery, run a SMART check to assess how bad the drive is. Critical attributes to watch:

• 0x05 Reallocated Sectors Count: sectors the drive has already replaced with spares. Any non-zero value warrants attention; rapidly rising values indicate active drive failure.
• 0xC5 Current Pending Sector Count: sectors that returned errors but haven’t been reallocated yet. Non-zero is a red flag for impending bad sectors.
• 0xC6 Offline Uncorrectable Sector Count: sectors the drive has confirmed are bad. Non-zero confirms physical damage.
• 0xC8 Write Error Rate: count of CRC errors during writes. Non-zero indicates active controller-side issues.

Step 3: Image the drive with ddrescue

Once you’ve confirmed the drive itself is the source of CRC errors, image the drive immediately. Don’t try to recover individual files first; don’t run CHKDSK; don’t reformat. Each operation against a drive with CRC errors risks pushing it from “recoverable with care” to “unrecoverable.” The standard tool is GNU ddrescue, designed specifically for this scenario.⁷

Step 4: Recover from the image

Once the drive is imaged, run recovery against the image rather than the original drive. The image is read-only-friendly (you can’t make it worse no matter what you do), and recovery against it doesn’t add stress to the failing source drive. Recovery tools that work against disk images:

• EaseUS Data Recovery Wizard: can mount and scan disk image files. Runs Quick Scan and Deep Scan against the image content.
• R-Studio: robust image-mounting support. The professional-grade choice for complex recovery scenarios.
• Disk Drill: supports mounting common image formats (RAW, E01) and scanning them directly.
• PhotoRec (free): file-system-agnostic file carving. Works on disk image files directly.

The most common bad advice for CRC errors is to run chkdsk /r. The advice surfaces in countless help articles and Microsoft support documentation. For drives with important data, this advice is dangerous. Understanding why requires understanding what CHKDSK actually does.⁸

What CHKDSK /r does

CHKDSK with the /r flag does two things: first, it checks the file system metadata for inconsistencies and fixes them; second, it reads every sector of the drive looking for bad sectors. When it finds a sector that returns errors, it tries to read it multiple times, then attempts to relocate the data to a good sector and mark the original as bad. The relocation attempt involves reading the sector successfully (which by definition it just couldn’t do) or, failing that, writing zeros to the sector and marking it bad in the file system.

Why this destroys recoverable data

When CHKDSK encounters a sector returning CRC errors, the data in that sector is partially readable in many cases. A bad-sector-tolerant imager (ddrescue) can retry the read multiple times and often gets the data eventually. CHKDSK doesn’t have this retry-and-image philosophy; it makes a few attempts and then writes the sector as zeros. After CHKDSK has run, the partially-readable bad sector contains zeros, and any data that ddrescue might have eventually recovered is gone. This is the same trap as bad sector recovery generally; tools designed for maintenance, not recovery, prioritize getting the file system back to working state over preserving every recoverable byte.

When CHKDSK is appropriate

• The data isn’t valuable and you just want the drive functional again. CHKDSK can quickly restore a drive to working order, accepting some data loss.
• You’ve already imaged the drive and recovered what you needed. CHKDSK on the original drive after recovery is fine; the image preserves the original state.
• The CRC error is logical, not physical (file system metadata corruption rather than bad sectors). CHKDSK can sometimes repair file system damage that wouldn’t respond to other approaches.
• The drive is still under warranty and you plan to RMA it. CHKDSK may surface enough errors that the manufacturer accepts the warranty claim.

👥 Researched & Reviewed By

Marcus Whitfield

Data Recovery Software Analyst & Senior Writer

All Articles X (Twitter)

Marcus has evaluated data recovery tools for more than six years across Windows, macOS, and Linux, from free utilities to enterprise-grade platforms. He writes the technical reference content on Data Recovery Fix, with particular focus on the diagnostic patterns that distinguish recoverable storage errors (cable issues, isolated bad sectors) from genuine drive failure scenarios. CRC errors are the canonical example of a storage error message users misread as catastrophic when the actual cause is often trivial.

B.Sc. Computer Science 6+ years data recovery evaluation Storage error diagnostics

Rachel Dawson

Technical Approver · Data Recovery Engineer

All Articles X (Twitter)

Rachel brings over twelve years of cleanroom data recovery experience, with regular work on drives that arrive at the lab after the customer has already run CHKDSK and made the recovery harder. She has seen every variant of the CRC error path: the trivial cable issue that resolved with a USB port swap, the failing drive imaged successfully with ddrescue, the drive that arrived too late after CHKDSK had zeroed out the recoverable sectors. Her work informs the imaging-first workflow recommended throughout this entry.

12+ years data recovery engineering PC-3000 certified CRC error diagnostics