
A CRC error means data changed between the moment it was sent and the moment it arrived, and the system detected the mismatch. It's a corruption alarm — not a corruption cause. The check did its job; something else broke.
So if Windows just hit you with "Data error (cyclic redundancy check)", or your switch port's CRC error counter is climbing, take a breath. You're not looking at one problem with one fix. You're looking at an alarm that fires identically across four completely different situations.
In this guide, I'll show you what a cyclic redundancy check actually does, how to identify which of the four scenarios you're in, and a step-by-step fix for each one.
Let's dive in.
Before you run a single command, find your row in this table. I've ordered it by how often I see each case. The severity column matters more than anything else on this page, because the wrong first move — running a repair tool on a dying drive, for instance — can turn a recoverable problem into a permanent one. Read across, then jump to the matching section below.
Where you see it | Typical cause | Severity | First action |
|---|---|---|---|
Archive extraction ("CRC failed in [file]") | Incomplete or interrupted download | Low | Re-download from source |
SMART attribute 199 (UDMA_CRC_Error_Count) | Loose or faulty SATA cable | Low–Medium | Reseat/replace SATA cable |
Network interface ( | Bad cable, failing transceiver, duplex mismatch | Medium | Check late collisions counter |
Storage drive ("Data error (cyclic redundancy check)") | Bad sectors, failing drive | High | Back up or image before repairing |
Notice the pattern. Three of these four are cheap fixes. Only one of them threatens your data — and that's the one where people reflexively run chkdsk first.

Most articles get this part wrong. They treat a CRC error like a single disease with a single cure. It isn't. It's a smoke detector. The alarm sounds the same whether the fire is a loose SATA cable or a truncated ZIP file, and understanding that is what saves you four hours of blind guessing. So let's cover the mechanism once, properly, and then everything downstream gets easier.
A cyclic redundancy check is an error-detecting code. Detecting — not correcting.
Here's how it works in practice.
Before data gets sent or stored, the system runs a calculation on it and produces a short check value — a mathematical fingerprint. That value rides along with the data.
When the data arrives, the receiving side runs the same calculation. Fingerprints match? Great. Mismatch? CRC error.
Wikipedia puts it cleanly: blocks of data get a short check value attached based on the remainder of a polynomial division of their contents, and on retrieval the calculation is repeated so corrective action can be taken against data corruption.
I love this design because it's cheap, fast in hardware, and brutally effective.
Nobody clicked here for polynomial algebra, I know. But stick with me for two paragraphs, because knowing why CRC catches errors tells you precisely which failures it will and won't catch — and that determines how much you should actually worry when you see one. This is the difference between fixing the problem and running random commands off a forum post.
The sender and receiver agree on a generator polynomial, which is essentially a divisor.
The sender appends R zeros to the data, then performs modulo-2 division — which is just XOR — until the remainder is smaller than the divisor. That remainder becomes the check code.
The receiver repeats the math. Mismatch means corruption.
CRC was proposed by W. Wesley Peterson in 1961, and it survived six decades because it's cheap in silicon and shockingly accurate.
How accurate? An n-bit CRC catches any single error burst no longer than n bits, plus roughly (1 − 2⁻ⁿ) of the longer ones. For CRC-32, that's 99.9999998% of long error bursts caught — you'd need roughly 4.3 billion corrupted frames before one slipped through undetected.
Not all CRCs are the same size, and the size determines the tradeoff between speed and collision risk. You'll run into these names constantly in networking and storage documentation, so here's the cheat sheet. Pay particular attention to the last two rows, because the difference between them is the single most-repeated error on the internet about this topic.
Variant | Check bits | Common use | Notes |
|---|---|---|---|
CRC-8 | 8 | Sensors, embedded, SMBus | Fastest, lowest energy, highest collision risk |
CRC-16 | 16 | Modbus, USB, older serial protocols | Middle ground |
CRC-32 | 32 | Ethernet (IEEE 802.3), ZIP, PNG, gzip | Polynomial 0x04C11DB7 |
CRC-32C | 32 | iSCSI, SCTP, ext4 metadata | Castagnoli, 0x1EDC6F41 — not Ethernet |
Quick detour, because this one genuinely bugs me. A lot of blog posts — and a lot of AI chatbots — will confidently tell you Ethernet uses CRC-32C, the Castagnoli variant. I've watched this claim get copied across dozens of sites because nobody bothers to open the standard. So let's open the standard.
RFC 3385 states the real IEEE 802.3 generator polynomial:
g(x) = x³² + x²⁶ + x²³ + x²² + x¹⁶ + x¹² + x¹¹ + x¹⁰ + x⁸ + x⁷ + x⁵ + x⁴ + x² + x + 1
CRC-32C is what iSCSI uses. Ethernet uses standard CRC-32.
Now you know something most of the internet doesn't.
Here's where most guides fall apart. They pick one scenario, write 1,500 words about chkdsk, and strand you if your problem lives elsewhere. CRC errors appear in four wildly different contexts with four different root causes — and running the wrong fix can destroy data. So let's sort out which one you've got.
If you're a network engineer, this is your version. You run show interfaces, and the input errors and CRC counters tick upward like a taxi meter. Throughput is garbage, users are complaining, and nothing in the config looks wrong. Good news: CRC errors here are almost never software problems. They're physical layer problems wearing a software costume — and physical problems are findable.
Cisco's official troubleshooting documentation lists the usual suspects:
Damaged copper, fiber, or Direct Attach Cables (DACs)
Failing transceivers — SFP, SFP+, QSFP
Dirty or damaged patch panel ports
Defective line cards, ASICs, or fabric modules
A bad NIC on the far end
MTU mismatch, which truncates frames
Then there's the classic: duplex mismatch.
Cisco's switch port guide is blunt — if FCS, CRC, alignment errors, or runt counters increment on a full-duplex link, go check duplex. One side full, one side half. Symptoms are brutally slow performance, intermittent connectivity, and dropped sessions.
This is the tip I'd keep if you forgot everything else in this section. It separates the two most common network CRC causes using counters you already have on screen, without touching a cable or opening a ticket with your ISP. Run show interfaces and look at one number.
Look at late collisions.
CRC climbing, late collisions at zero → cable or noise problem. Corruption isn't a collision-domain event.
CRC climbing alongside late collisions → duplex mismatch. Go fix speed/duplex config.
Two counters. One answer.
Worth knowing too: runts are frames under 64 bytes with a bad CRC, and giants are non-jumbo frames over 1518 bytes with a bad FCS. They travel in packs with CRC errors.
This is the scary one, and it deserves a little fear. You're copying a folder or double-clicking a drive, and Windows slams the door: "D:\ is not accessible. Data error (cyclic redundancy check)." Years of files sitting behind that message. What you do in the next ten minutes matters more than anything else in this article, so read this section before you touch a repair tool.
SalvageData's recovery engineers note the error also surfaces in File Explorer, in CHKDSK output, and as a SMART alert.
On a spinning hard drive it usually points to bad sectors — spots the read/write head can't reliably access. As sectors degrade, the drive retries the read repeatedly before reporting failure. That's why the drive feels slow before it errors out.
Here's the part that gets buried in every competing article, usually somewhere around paragraph forty, after they've already told you to run the command. It belongs at the top, because it's the difference between a recoverable drive and a shredded one. If your data is worth more than the hardware, this paragraph is the whole article.
CHKDSK writes to the drive during repair. On a drive already struggling to read, those writes can overwrite sectors a recovery engineer could have imaged first.
Translation: image it before you repair it.
Also remember — CRC tells you data is intact, but can't fix it. On mismatch it halts the operation and requests a retry. Smoke detector, not fire extinguisher.
Deep breath — this category is usually good news. You ran CrystalDiskInfo or smartctl, spotted UDMA_CRC_Error_Count glowing yellow, and assumed your SSD is dying. Almost certainly not. This attribute rarely indicates drive failure. It means the drive and motherboard had trouble talking. Different problem, much cheaper fix — often a $5 cable.
Unraid's documentation explains these indicate a communication problem between drive and host, not mechanical failure. The culprits:
Loose or poorly seated SATA cables (they work loose from vibration)
Faulty or cheap SATA cables
Power delivery issues from splitters or an overloaded PSU
An unseated controller card
Rarely, an actual drive fault
These two rules answer roughly every SMART-199 question I've ever seen asked on a hardware forum, and they point in opposite directions. The first one talks you down off the ledge. The second one is the genuine red flag that means stop reading and start backing up.
Rule one. The counter is non-resettable. It logs every CRC error the drive has ever recorded. A value of 76 that hasn't moved in two years is history, not a crisis. Watch the trend, not the number.
Rule two. If SMART attribute 197 (Reallocated Sector Count) is rising alongside 199, that's a different story entirely — the drive is actively failing. Back up immediately.
One free hardware tip: don't run SATA data cables parallel to power cables. If they must touch, cross them at 90 degrees to reduce crosstalk and electromagnetic interference.
Last one, and by volume the most common. You download a 4GB archive, wait patiently, hit extract, and WinRAR tells you it's corrupt. Rage follows. But this CRC error is the friendliest of the four — the fix is usually "download it again," and the checksum did exactly what it was designed to do: stop you from installing garbage.
The mechanic: when a file is compressed, the tool calculates and stores a checksum. On extraction it recalculates and compares. If they don't match, the file being unpacked isn't the file that was packed. This matters more for some formats than others — raster image files, for example, degrade differently than vector files when even a few bytes go missing.
Puget Systems points to incomplete downloads, storage device issues, and archive creation errors.
Large media files take the worst of this. A single interrupted transfer of a long screen recording or video export is enough to trigger a CRC failure on extraction — the bigger the file, the more chances there are for something to go wrong mid-download.
Learn to read the specific message — they mean different things:
"CRC failed in [filename]" → data stream damaged
"Cannot open file as archive" → header unreadable, often a truncated download
"Unexpected end of archive" → incomplete transfer
"Headers error" → index damaged, but data blocks may survive
Header corruption is frequently repairable. Damage deep in the compressed stream may only allow partial recovery.
Enough theory — let's fix it. I've ordered these from safest to most destructive on purpose, because the biggest mistake I see is people jumping straight to formatting or aggressive repair on a failing drive. Work down the list in order. Stop the moment your problem disappears. Don't skip ahead because you're impatient.
Network counter, drive dialog, SMART attribute, or archive extraction? Everything downstream depends on this. Use the quick-reference table near the top of this page.
Before any repair. Recovery software reads without writing. CHKDSK writes. This order is not optional.
Reseat the SATA or Ethernet cable. Swap for a known-good one. Try a different port. This alone resolves a large share of UDMA CRC errors and interface CRC errors.
Copy the problem file elsewhere. Can't copy it? The file is corrupt. Copies fine? The drive is your problem. Driver Easy's method — simple, and it works.
Open Command Prompt as administrator:
chkdsk X: /f /r
Replace X: with your drive letter. On a large or ailing drive this can take hours, and it can render some corrupted files inaccessible — which is exactly why Step 2 came first.
sfc /scannow
This scans for damaged Windows files and restores them from cached copies.
Pull a fresh copy from the source. Then try WinRAR's built-in repair (Alt+R), or enable "Keep broken files" to salvage partial data. A different extractor — 7-Zip 24.x or later — sometimes succeeds where the first gave up.
Most duplex mismatches happen because someone hardcoded one side and forgot the other. If you truly must hardcode, hardcode both ends to identical values.
Clicking sounds, unusual delays, or attribute 197 climbing alongside 199? Power it down and call a professional recovery service. Every extra spin-up costs you data.
People use these three words interchangeably, and that confusion causes real security mistakes. They solve genuinely different problems, and picking the wrong one leaves a gap an attacker can walk straight through. Here's the distinction in one table, then the one-line takeaway underneath.
Simple checksum | CRC | Cryptographic hash | |
|---|---|---|---|
Example | Sum-of-bytes, parity | CRC-32, CRC-32C | SHA-256, BLAKE3 |
Catches accidents | Weakly | Very well | Very well |
Catches tampering | No | No | Yes |
Speed | Fastest | Very fast | Slower |
Typical use | Legacy protocols | Ethernet, ZIP, SATA | Downloads, signatures, security |
The takeaway: CRC checks integrity, not authenticity. It catches a file that got mangled. It won't catch a file someone deliberately altered, because an attacker can simply recalculate the checksum. That's what cryptographic hashes and digital signatures exist for.
Is a CRC error serious?
It depends entirely on where it appears. An archive CRC error is trivial — re-download the file. A drive-level "Data error (cyclic redundancy check)" is serious and may signal a failing disk.
Can a CRC error be fixed?
The underlying corruption usually can't be reversed, because CRC detects but doesn't correct. What you fix is the cause — the cable, the transceiver, the duplex setting, or the download.
Does a CRC error mean my hard drive is failing?
Not necessarily. SMART attribute 199 (UDMA_CRC_Error_Count) points at the cable, not the disk. But if attribute 197 is rising alongside it, the drive is genuinely failing.
What's the difference between a CRC error and a checksum error?
Functionally none in most software. WinRAR uses both phrases for the same event: the recalculated value didn't match the stored one.
Can CHKDSK make things worse?
Yes. CHKDSK writes to the drive during repair, and on a drive already struggling to read, those writes can overwrite sectors a recovery lab could have imaged. Back up first.
Why does my UDMA CRC error count keep growing?
Because the counter is non-resettable — it never clears. A static count is old history. A rising count means an active cable, connector, or power problem.
Do CRC errors cause slow internet?
On a network link, yes. Corrupted frames get discarded and retransmitted by upper-layer protocols, which shows up as latency and throughput loss.
Is CRC the same as a hash?
No. CRC is designed for accidental corruption. Cryptographic hashes like SHA-256 are designed to resist deliberate tampering.
Here's what I want you to walk away with, because it reframes the whole panic response. The message on your screen isn't the failure. It's evidence that a failure already happened somewhere upstream — and that a sixty-five-year-old algorithm caught it before you did.
A CRC error is the system doing its job.
Find your row in the table at the top. Back up before you repair. Check the cable before you blame the hardware.
Now go check your cables.

Daniel Harper is a B2B marketing consultant who helps professionals and founders grow their LinkedIn presence through smart engagement strategies. He writes about AI tools, reply tactics, and building authentic professional networks that actually convert.
AIReplyBee is your AI-powered LinkedIn reply generator that helps you create authentic, engaging responses in seconds.
Generate your first replyDoes LinkedIn have read receipts? Yes and they're mutual. Learn what every icon means, plus how to read messages without them knowing.
Screen record on Mac in 5 seconds with Shift+Command+5. Learn the exact fix for recording system audio, plus permission errors solved. Free, no apps.