It would definitely be interesting to know more of the context around this code in Windows - when it existed, and which processor models would enable it. I'm pretty sure some of the x86-compatible processors made by several vendors over a couple of decades weren't ECC all the way through.

The way I remember it, when this happened on our Sun E10Ks, the RAM was ECC but the cache was not.

Maybe I misremember. It was 20 years ago.

That was my thought process as well, that an early silicon spin / chip wasn't ECC because it would change state frequently and the circuit budget wasn't worth a soft error; but the external RAM might be ECC because a longer running state might not have such a refresh/detection of error.

I agree that these days I'm unaware of any "serious" CPU where the data isn't at least protected by at least a parity bit on chip.

RISC-V : spec mentions ECC, but in a phrasing that makes it clearly optional. https://github.com/riscv/riscv-v-spec/blob/master/v-spec.ado...

"Many processors use error correction codes in the on-chip cache, including the Intel Itanium and Xeon[28] processors, the AMD Athlon, Opteron, all Zen-[29] and Zen+-based[30] processors (EPYC, EPYC Embedded, Ryzen and Ryzen Threadripper), and the DEC Alpha 21264.[23][31]" https://en.wikipedia.org/wiki/ECC_memory#Cache

I prefer to always use ECC and layers of defenses where persistence of data is in question. Jeff Atwood's reference does point to other options, assuming that validation is baked in to the storage process and distributed in such a way as to identify and correct errors across a distributed infrastructure rather than a single system; the distributed nature means it could be more resilient and the validation of data at rest / comparing results is arguably a higher level of integrity than just ECC can provide. https://blog.codinghorror.com/to-ecc-or-not-to-ecc/