Re: Some Registry Measurements
- From: "John John (MVP)" <audetweld@xxxxxxxxxxx>
- Date: Fri, 14 Nov 2008 19:06:37 -0400
Twayne wrote:
Twayne wrote:
The large size of the text file and lack of any kind of crc or hash
control on it is why corruption can happen to it so easily. The
registry is even more exposed to corruption from the operating
system glitches, malware and poorly written apps than some other
parts of the system. Especially when you consider the very large
number of times the registry is written to or read even while a
computer is sitting idle.
Corruption of the registry does not happen as easily as you might
think, quite to the contrary the ACID properties of registry
transactions and the use of transactional logs makes the registry
very robust indeed! The registry is not *more* exposed to corruption, the above makes it
*less* exposed to corruption than almost any other file on the hard
disk.
John
ACID "properties"? I assume you're referring to trasnactional management, callbacks, pre/post and such. There is something to that, surely, and I can't argue against that.
I do have to admit , that in the overall, it is NOT "more exposed ... " as I said. That was a bad statement. The registry in XP is actually pretty robust. It's also impractical in its present format/methodology for the registry to ever be subject to hashing of any type without serious performance hits, I'm sure.
Corruption still happens though, and too often IMO. The very nature of the registry almost invites corruption via the very high activity it's constantly submitted to.
Registry corruption is not as prevalent as you make it out to be. Many, if not must users will never experience registry corruption. Users may suffer problems caused by improper, missing or deleted entries in the registry but these problems are rarely caused by corruption, these problems are usually caused by deliberate user actions, by the user's applications, by registry cleaners or by malware. Very rarely are those problems caused by corruption, users should not confuse registry damage cause by their willful actions or that of their applications with registry corruption.
Some users may be so unfortunate as to get the infamous "Windows could not start because the following file is missing or corrupt: \WINDOWS\SYSTEM32\CONFIG\..." error message when they boot their computer but even that is not something that most users will ever have to deal with. Also, although the error may be caused by registry corruption, quite often the corruption problem is actually caused by disk corruption which in turn leads to corruption or missing registry files, the corruption is not usually caused by registry activity while Windows is running.
ACID: Atomicity, Consistency, Isolation, and Durability
[Quote]
*Atomicity and Hive Recovery in the Registry*
The Registry ensures atomicity of individual actions. This means that any change made to a value (to set, delete, or save) either works or does not work: The result will not be a corrupted combination of the old and new configuration even if the system stops unexpectedly because of power failure, hardware failure, or software problems. For example, if an application sets a value for an entry and the system shuts down while this change is being made, when the system restarts, the entry will have either the old value or the new value, but not a meaningless combination of both values. In addition, the size and time data for the key containing the affected entry will be accurate whether the value was changed or not changed.
*Flushing Data*
In Windows NT, data is written to the Registry only when a flush occurs, which happens after changed data ages past a few seconds, or when an application intentionally flushes the data to the hard disk.
The system performs the following flush process for all hives (except for the System hive):
1. All changed data is written to the hive's .log file along with a map of where it is in the hive, and then a flush is performed on the .log file. All changed data has now been written in the .log file.
2. The first sector of the hive file is marked to indicate that the file is in transition.
3. The changed data is written to the hive file.
4. The hive file is marked as completed.
Note If the system shuts down between steps 2 and 4, when the hive is next loaded at startup (unless it's a profile hive that is loaded at logon), the system sees the mark left in step 2, and proceeds to recover the hive using the changes contained in the .log file. That is, the .log files are not used if the hive is not in transition. If the hive is in transition, it cannot be loaded without the .log file.
A different flush process is used for the System hive because it is an important element during system startup and is used too early during startup to be recovered as described in the previous flush process.
The System.alt file contains a copy of the data contained in the System file. During the flush process, changes are marked, written, and then marked as done. Then the same flush process is followed for the System.alt file. If there is a power failure, hardware failure, or software problems at any point during the process, either the System or System.alt file contains the correct information.
The System.alt file is similar to a .log file except that at load time, rather than having to reapply the logged changes, the system just switches to System.alt. The System.alt file is not needed unless the System hive is in transition.
[end quote]
http://www.microsoft.com/resources/documentation/windowsnt/4/workstation/reskit/en-us/23_regov.mspx?mfr=true
John
.
- References:
- Some Registry Measurements
- From: Twayne
- Re: Some Registry Measurements
- From: John John (MVP)
- Re: Some Registry Measurements
- From: Twayne
- Some Registry Measurements
- Prev by Date: RE: Missing help file
- Next by Date: Re: Places bar question for the OS (vs. Office) ... small icons problem.
- Previous by thread: Re: Some Registry Measurements
- Next by thread: Re: Some Registry Measurements
- Index(es):
Relevant Pages
|
