CRC mismatch troubleshooting checklist

CRC results depend on more than the polynomial. Width, initial value, input reflection, output reflection, final XOR, input encoding, and byte order must all match — a difference in any one of these can produce a different checksum even when both tools are, in every other respect, computing correctly. Before comparing implementations line by line, run the standard ASCII test string 123456789 through each one and compare the result to that model's own published check value, not directly to each other.

If both tools agree with their respective model's published check value but still disagree with each other on real input, they are not implementing the same CRC model at all — no amount of parameter tweaking will make two different models agree, and the fix is to identify which model the protocol or file format actually specifies. If neither tool matches its own published check value, the bug lives inside that implementation, and the checklist below narrows down where.

Work through the parameters below in this order. Each one can independently make two otherwise-identical calculators disagree, and checking from the most structural (width) to the most easily overlooked (byte order) rules out the fastest, most common causes first.

Reflection is the parameter most often implemented backward, because RefIn and RefOut look symmetric but are not necessarily applied the same way inside a given engine. A frequent bug is reflecting each input byte, using a reflected polynomial with a right-shifting register — which already accounts for RefIn — and then reflecting the final output again without checking whether the engine's convention already produced the correct orientation. The result is a value that is wrong in a way that looks like a sign or byte-order bug rather than a double reflection.

Input encoding rarely produces an error message — a text field and a hex field both accept the same-looking characters and both happily produce a checksum, so a wrong choice fails silently. Before comparing two implementations, print or log the exact byte sequence each one is about to feed into the CRC. If those bytes differ, the CRC engines themselves are irrelevant; fix the input first.

First, confirm the byte sequence each tool is hashing is identical — log it if the tool allows it. Second, run the ASCII string 123456789 through both and compare each result to that model's published check value rather than to each other; a mismatch here means the models themselves differ, not the input. Third, if both match their own check values but the real input still disagrees, work down the checklist above one parameter at a time against the algorithm's published Width, Poly, Init, RefIn, RefOut, and XorOut, rather than guessing which one is wrong.

If sample input/output pairs are available but the model name is not confirmed, the CRC identifier tool recalculates a data-and-checksum pair against every catalog model and reports every one that reproduces it — a faster way to find which model is actually in play than testing checklist items against a guess. When a message and its CRC field both need validating together rather than compared separately, the residue check described in the CRC residue guide validates the complete codeword in a single pass.