Giving up on Vista

AndyC wrote:


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.)

AndyC wrote:



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.

AndyC wrote:



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.

Bet you turned off UAC.

Bas wrote:

I'm wondering what, exactly, can go wrong in the registry. The only thing I often hear is that it's 'messed up' or 'corrupted'. I'm wondering what exactly is going on, and why. Why didn't this happen with all those separate .ini files, for instance?

The registry is saved to disk during shutdown. If the power goes during shutdown, this file can be partially damaged which means that when power is restored, some of the registry is dead, which means all programs that rely on the registry will be dead.

This can typically be solved with System Restore so long as System Restore has not been disabled.

AndyC wrote:


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.

You could huffman encode it for an optimum, self-repairing checksum.

AndyC wrote:


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.

Are you sure the registry isn't type-safe? That would surprise me.

evildictaitor wrote:



Bas wrote: I'm wondering what, exactly, can go wrong in the registry. The only thing I often hear is that it's 'messed up' or 'corrupted'. I'm wondering what exactly is going on, and why. Why didn't this happen with all those separate .ini files, for instance?

The registry is saved to disk during shutdown. If the power goes during shutdown, this file can be partially damaged which means that when power is restored, some of the registry is dead, which means all programs that rely on the registry will be dead.

This can typically be solved with System Restore so long as System Restore has not been disabled.

I see. So why isn't the registry written to disk on a per-application basis? Wouldn't that -only- corrupt the registry keys of the application that's 'being written'?

I realise some registry keys are shared, but wouldn't this at least solve part of the problem?

Bas wrote:


I see. So why isn't the registry written to disk on a per-application basis? Wouldn't that -only- corrupt the registry keys of the application that's 'being written'?

I realise some registry keys are shared, but wouldn't this at least solve part of the problem?

I don't know for sure, but I'd suspect that the registry is kept in memory and only written to disk every now-and-then, since registry access is fairly frequent, and disk operations are expensive.

As a result (I would guess) that the entire structure of the registry needs to be written down again to the disk every certain number of registry write operations and during system shutdown.

Why they don't do multiple redundancy checking is beyond me though.

Apogeum wrote:


Also I need tools to work not toys. Vista is a toy (no offense). But I am really looking foward to explore Windows 2008 Server.

Server 2008 is the same damn thing as Vista SP1.

AndyC wrote:

How do you checksum a DWORD?

Because there aren't any 8- or 16bit checksum algorithms, right?

evildictaitor wrote:


Are you sure the registry isn't type-safe? That would surprise me.

Offering string, DWORD and blobs without any sort of format checking isn't exactly typesafe. Obviously DWORDs and blobs are rather hard to check for validity without injecting tons of third-party code into the registry code. But most things are stored as strings. Creating the registry subtree, attaching regexes or whatever else mechanism to each string key and validating everything on application install time would allow the application to catch itself going nutso.

Tom Servo wrote:


Because there aren't any 8- or 16bit checksum algorithms, right?

Not that are performant and reliable enough to be worth bothering with, no.

Sven Groot wrote:

Explain to me how it knows something went wrong? The only thing I can think of is a CRC for the registry, which would need recomputing every time the registry is changed. That'll be nice for performance.

The registry is a tree like structure. Make use of that fact. ZFS doesn't crap all over itself during metadata updates, either, which is checksummed to no end and usually involved updating all checksums from the modified filesystem block, going up the metadata tree up to the uberblock.

littleguru wrote:


How about a log file like they use in databases? You could roll back if you see that one of the writes didn't work out (power went off or similar stuff) - or even restore the database (=registry) from a backup version if rolling back isn't working anymore.

Congratulations, you've just invented Transactional Registry support.

littleguru wrote:


How about a log file like they use it in databases? You could roll back if you see that one of the writes didn't work out - or even restore the database (=registry) if rolling back isn't working anymore.

You mean some kind of transactional registry... (or even just try searching)? <summon Jason, as transactional stuff seems to be one of his favourite things>

AndyC wrote:



littleguru wrote:  How about a log file like they use in databases? You could roll back if you see that one of the writes didn't work out (power went off or similar stuff) - or even restore the database (=registry) from a backup version if rolling back isn't working anymore.

Congratulations, you've just invented Transactional Registry support.

Dammit! He got there first!

littleguru wrote:

why is the registry no relational database after all

Because it doesn't need 99% of the features of a relational database?