But that really doesn't work, because it's impossible to know whether it's the checksum that's corrupt or the data itself. It's just too small a datastructure to try and implement that sort of validation. Not to mention the actual overhead of trying to compute that in any reasonable way.
overhead aside, I don't care whether the checksum or the data is corrupt, the assumption is that if something's corrupt then everything's suspect. (And it's time to reach for the backup.) I know that a simple bit is primitive (and allows half the corruptions to escape undetected.) but it's better than nothing.
Also, there's not a huge overhead on a checksum for an individual item, that's why you may choose to do it on an individual level. (Rather than the entire registry.) Well, not when you compare it to just getting disk access to begin with. (I'm pretty sure registry access is going to be I/O bound, almost regardless of how much computation has to be done to ensure data integrity.)
What's more, it's not a very effective strategy. Registry corruption is usually caused by one of two things:
1) A crash during read/write operations, leading to an on-disk corrupt structure. At that point you're looking a significant overhead on every read/write operation for the sake of a tiny possibilty of data recovery in the event of a crash.
Granted there's probably a more general means of determining whether the disk is corrupt and what files the corruption spreads to, and that would be preferable to any structure-specific tinkering. But if it turns out you can't definitely say which files a disk corruption affects, then this is a next-best measure type thing.
2) Applications writing invalid data. No amount of checksumming helps there because what's getting written is technically what the application wants to write. Enforcing type-safety on the registry might help, but again it's a lot of overhead when applications are
supposed to be doing the right thing.
Well, you can't solve this no matter what you try, (even enforcing type safety on the registry doesn't prevent people writing nonsensical values of the right type.) so it's not even worth trying to fix a broken applications behaviour from here.
But it's a good point though, I could be evil and ask for a change in the registry API that asks for the application to compute the checksum on writing and throws a fit if they don't match. But somehow I think breaking nearly every single windows application ever just to solve a minor problem of registries occasionally being corrupted just isn't worth it. (Also how would they know how to calculate the checksum? There'd have to be a "calculate checksum" API, and then people'd just pass that nonsense and we'd be back to square one.)
Not that I'm saying my idea would work, just that you'll have to think of a more definite reason as to why it wouldn't than those.