What Is a Checksum Error? How to read the alarm and fix it

In one week last year I watched two people meet a checksum error, and neither of them had the problem they thought they had.

The first was a friend whose ten-year-old desktop greeted her with white text on black, CMOS Checksum Error - Defaults Loaded, and who had already started pricing a replacement, convinced her drive had died and her photos with it. Her drive was fine. She needed a coin cell that costs two dollars.

The second was a developer who downloaded the same 4 GB image three times on conference Wi-Fi and got three different SHA-256 values. He spent an afternoon on SSD diagnostics. The SSD was fine too. The network wasn't.

Both made the same mistake, and it's the one this guide exists to fix: they read a checksum error as a diagnosis when it is only an alarm. It tells you that two numbers disagree. It tells you almost nothing about why.

A checksum error means the data changed since someone last did the maths on it

It isn't vague, then. It's precise about a very small thing. Your job is to work out which layer raised it: that narrows hundreds of causes to two or three.

How the check actually works

Every checksum system works the same way, whether it guards 50 bytes of BIOS settings or a 4 GB ISO:

• Write side. Run the data through a function; get a small fixed-size number of 16, 32 or 256 bits. Store it alongside.

• Read side. Run the same function over the data you actually received.

• Compare. Same? Carry on. Different? Raise a checksum error.

The function is built so that flipping one bit changes the output completely. That's the trick: it turns "did any of these four billion bits move?" into "are these two short numbers equal?"

Figure 1: the alarm, not the burglar. The check sits at the far end of a long chain. A mismatch proves something in it misbehaved; it never says which link. Note the last item on the journey: not every corruption is an accident.

How a checksum error occurs: what actually changed the bytes

The check fires because something upstream altered the data. That "something" is almost always one of six things, and each one leaves a different fingerprint.

Five places you'll actually meet one, and how to tell them apart

Almost every checksum error comes from one of five layers. Find your string in the table; that single step does most of the diagnostic work.

Figure 2: five independent checks, five meanings. They don't know about each other. A clean Ethernet FCS says nothing about your disk; a clean disk checksum says nothing about whether the file is the one the publisher shipped.

How often does data actually go bad? Someone counted.

Most articles hand-wave about "rare but possible". Several organisations counted, at enormous scale, and published. The picture is consistent: corruption is rare per event and inevitable at volume.

The disk figures predate modern SSDs and the traces predate modern link speeds, but they remain the largest published field studies of their kind.

The CMOS checksum error, properly explained

Since the IBM PC/AT, x86 machines have kept their settings in low-power RAM on the same chip as the real-time clock: 64 bytes, roughly 50 of them configuration. The classic layout stores a 16-bit sum of registers 0x10–0x2D at addresses 0x2E–0x2F. That sum is the CMOS checksum, and POST recomputes it at every power-up.

So the message means exactly what it says: the settings I read back don't add up to the number I wrote down. Modern UEFI keeps far more in flash, but the clock, the coin cell and the error text all survived.

Why the battery is the prime suspect, with numbers

That RAM is volatile. It only remembers because the coin cell holds it up whenever mains and standby power are gone. A CR2032 is rated around 235 mAh (Energizer's datasheet, to 2.0 V); a healthy RTC circuit draws 1–10 µA. Divide one by the other:

Figure 3: the arithmetic behind "just replace the battery". Idealised: 235 mAh ÷ drain, ignoring temperature and self-discharge. A healthy board shouldn't eat cells, so one dying inside two years points at a leak. And the cell only drains when standby power is absent, which is why the machine that lives unplugged in a cupboard is always the one that fails.

The fix, in the order that saves time

1. Check the clock first. It's a free diagnosis.  Reset to 1980? The RAM lost power: battery. Clock correct but the error persists? The cell is fine, and something else scrambled the settings: a flash update, a jumper, a board fault.

2. Photograph your settings first.  Boot order, SATA mode (AHCI vs RAID), XMP, secure boot. Getting these wrong after a reset turns a two-dollar fix into "my PC won't boot".

3. Replace the CR2032 with the machine plugged in and the PSU switch on.  Standby power holds the settings while the cell is out, so you often skip reconfiguring. Match the exact code, because a CR2025 fits the holder but carries less charge.

4. Load defaults, re-enter your settings, save, reboot twice.  The second boot is the test.

5. If it returns within days, stop buying batteries.  A fresh cell dying in a week is a hardware fault, so measure the draw with a multimeter in series. Single-digit µA is healthy; tens or hundreds mean a leak. Check the clear-CMOS jumper and holder tension too.

When a download's hash doesn't match

First, check you're comparing like with like. A startling share of "checksum errors" turn out to be someone checking SHA-256 against a published MD5, or hashing the wrong file.

The last one is the habit worth building: let the tool compare. Human eyes reliably miss one transposed character in sixty-four.

If it genuinely doesn't match, work outward:

•  Re-download from a different mirror. If the second copy matches, the first was damaged in flight and you're done.

•  Suspect the network before the hardware. Captive portals, corporate proxies and stale CDN edges all produce reproducible mismatches on a healthy machine. Try another network, or a torrent, which verifies each piece independently.

•  If two downloads on two networks both fail, look locally. Now RAM and storage are worth suspecting: memory test overnight, check SMART.

Three times a checksum error isn't telling you the truth

The check is not an oracle. It fails in three well-documented directions.

1. The false alarm: your capture is lying, not your network

Open Wireshark on a modern machine and a third of your outbound packets may be flagged [TCP CHECKSUM INCORRECT]. Nothing is broken. Your network card does checksum offloading, computing the checksum in hardware as the frame leaves, after your capture tool saw the packet. Wireshark's own documentation says so, and recommends switching checksum validation off.

2. The false comfort: a matching hash is not a safe file

In February 2016, attackers compromised the Linux Mint website, pointed the download link at a backdoored ISO, and edited the published MD5 to match it. Anyone who dutifully verified got a green light on malware. As the project lead noted, they could change anything in the database: checksums and mirror links alike.

So: a checksum proves a file is intact, never that it's authentic. It defends against accidents. Only a signature, verified against a key you obtained independently, defends against a person.

3. The false negative: errors that slip straight through

The 16-bit checksum guarding your TCP and UDP traffic was cheap to compute in 1981, and it shows. Stone and Partridge concluded it misses roughly 1 in 16 million to 1 in 10 billion corrupt packets, which is not a theoretical number at gigabit speeds. Their advice stands: if the data matters, checksum it at the application layer too.

The cryptographic hashes have their own version. MD5 collisions were found in about six seconds on a mid-2000s CPU. SHA-1 fell in 2017, when CWI and Google made two PDFs share one digest: 9.2 quintillion computations, 6,500 CPU-years plus 110 GPU-years, an estimated $110,000 of cloud time. That price only moves one way.

Which algorithm should you trust, and for what

These aren't interchangeable, and the difference isn't how paranoid you are. It's whether you're defending against accidents or against people.

Making the next one less likely, and less scary

My final verdict

I've come round to thinking of the checksum error as one of computing's more honest messages. It's blunt, it's early, and it's true: this data is not what it was. Everything that feels hostile about it (the timing, the wording, the way it lands before you've had coffee) is packaging around a useful signal.

My friend with the dead coin cell now has a machine that keeps time and a note in her calendar for 2029. The developer has a shell alias that verifies every ISO he downloads. Both took under an hour, once they stopped treating the alarm as the diagnosis and started asking which layer had raised it.

The errors worth fearing are the ones nobody prints: a file that reads back wrong without complaint, a CPU returning 5 for 2×3 once a week in one machine out of a thousand, a backup quietly rotting for three years. Every one of those is invisible because nothing was checking.

So when the screen goes black and the white text appears, that isn't the failure. That's the part that worked.