Registry Structure
|
|
For a better understanding of the logical structure of the registry, we will compare this to the file system that exists on the disk. The registry contains keys, which are similar to folders, and values, which can be compared to the files stored on the disk. Registry keys are container objects that can store both subkeys and values. Registry values contain the data (like the files). The top-level keys of this hierarchical structure are called root keys.
The convention used to name registry keys and values is also similar to the one used to name files and folders. For example, a typical folder path such as D:\WORK\BHV is comparable to a typical registry path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet.
In Windows 2000/XP and Windows Server 2003, the registry comprises the following five root keys: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_USERS, and HKEY_CURRENT_CONFIG. This hierarchical registry structure is illustrated in Fig. 1.7.
Figure 1.7: Hierarchical structure of the registry
All of the names of the root keys begin with the HKEY_ string, which indicates that this is a handle that can be used by a program. The handle represents the value used uniquely to identify the resource that can be accessed by a program. Table 1.1 lists the root keys that exist in Windows NT/2000, Windows XP, and Windows Server 2003 registries, the respective abbreviations that are often used to designate these root keys, and provides a brief description.
 |
| Root key | Abbreviation | Description |
|---|---|---|
| | ||
| HKEY_LOCAL_MACHINE | HKLM | Contains global hardware information and operating system data, including bus type, system memory, device drivers and other information used during the system boot process. Information on this key is applicable to all users who log on to the local system. Actually, this key is a placeholder that corresponds to no physical file stored on the disk. Instead, it contains other keys that do: (HKEY_LOCAL_MACHINE\SYSTEM, HKEY_LOCAL_MACHINE\SAM, HKEY_LOCAL_MACHINE\SECURITY, HKEY_LOCAL_MACHINE\SOFTWARE). This key has three top-level aliases - HKEY_CLASSES_ROOT, HKEY_CURRENT_CONFIG, and HKEY_DYN_DATA - a hidden registry key that serves as a placeholder for performance data lookups. |
| HKEY_CLASSES_ROOT | HKCR | This key contains information concerning filename associations, OLE (Object Linking and Embedding) information associated with COM objects, and file-class associations (this data is equivalent to the registry that existed in earlier Windows versions). Parameters contained in this key are equivalent to those stored under the HKEY_LOCAL_MACHINE\Software\Classes key. You can find more detailed information on the HKEY_CLASSES_ROOT key in the "OLE Programmer's Reference" manual included with the Windows Platform Software Development Kit (SDK). |
| HKEY_CURRENT_CONFIG | HKCC | Contains the configuration data of the current hardware profile. Hardware profiles are sets of modifications introduced into the standard configuration of services and devices set by the Software and System subkeys of the HKEY_LOCAL_MACHINE root key. The HKEY_CURRENT_CONFIG key contains only changed data. Moreover, the data contained in this key is also contained in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\HardwareProfiles\Current key. |
| HKEY_CURRENT_USER | HKCU | Contains the user profile of the user who is currently logged on to the system, including environment variables, desktop settings, network settings, and application settings. This key is a reference to the HKEY_USERS\user_SID key, where user_SID is the Security ID of the user who is currently logged on to the system. |
| HKEY_USERS | HKU | Contains all active user profiles, including HKEY_CURRENT_USER and the default user profile. Users who can access the server through the network do not have profiles under this key because their profiles are loaded remotely on their workstations. Windows NT/2000, Windows XP, and Windows Server 2003 require that each user who logs on to the system have his or her own user account. The HKEY_USERS key contains the \.Default subkey, which is used before any user logs on to the system. It also contains other subkeys associated with the Security ID assigned to the appropriate user. |
|
Registry data are parameters stored within registry keys. Each parameter has its own name, data type, and value. The three parts of the registry entry are also stored in the following order:
All registry data types defined and used in Windows NT/2000, Windows XP, and products of the Windows Server 2003 family are listed in Table 1.2.
|
| Data type | Description |
|---|---|
| | |
| REG_BINARY | Binary data. Most hardware components use binary information. Registry editors display this information in hex. |
| REG_DWORD | This data is represented as a 4-byte binary value (double word). Most services and device drivers use this data type. Registry editors display this data using binary, hex, or decimal formats. |
| REG_EXPAND_SZ | Expandable data string. This text string contains a variable name, which can be substituted by a variable value when called by an application. |
| REG_MULTI_SZ | Multi-string field. Normally, all values that actually represent lists of text strings have this data type. A NULL character is used as a separator. |
| REG_SZ | Text string in user-friendly format. Normally, this data type is used for component descriptions. |
| REG_DWORD_LITTLE_ENDIAN | 32-bit number in little-endian format. Equivalent of the REG_DWORD data type. When using the little-endian format, the lowest bit ("little end") appears first when representing the value. For example, the A02B hex value will be represented as 2BA0. The little-endian format is used in Intel processors. |
| REG_DWORD_BIG_ENDIAN | 32-bit number in big-endian format. In contrast to the little-endian format, the highest bit ("big end") appears first when representing the value. |
| REG_LINK | Unicode symbolic link. This data type is intended for internal use only. The REG_LINK is especially interesting because it allows one registry entry to reference another registry key or registry value. For example, if a registry contains the entry \Root1\Link with the REG_LINK data type and its value is \Root2\RegKey, and the RegKey key contains the RegValue value, then this value can be identified using the following two paths: Windows NT/2000, Windows XP, and Windows Server 2003 make active use of this method. For example, some of the root keys listed in Table 1.1 are links to the nested keys of other root keys. |
| REG_NONE | No defined data type. |
| REG_QWORD | 64-bit value. |
| REG_QWORD_LITTLE_ENDIAN | 64-bit value represented using little-endian notation. Equivalent of the REG_QWORD data type. |
| REG_RESOURCE_LIST | List of hardware resources, which are only used in HKEY_LOCAL_MACHINE\HARDWARE. |
| REG_FULL_RESOURCE_DESCRIPTOR | Hardware resource handle, which is only used in HKEY_LOCAL_MACHINE\HARDWARE. |
| REG_RESOURCE_REQUIREMENTS_LIST | List of hardware resources, which is only used in HKEY_LOCAL_MACHINE\HARDWARE. |
|
Registry Data Storage
All Windows NT-based operating systems, including Windows 2000, Windows XP, and products of the Windows Server 2003 family, store registry entries as an atomic structure rather than simply as one large file. The registry is subdivided into components, called hives, for their resemblance to the cellular structure of a beehive. The Registry hive is a discrete body of keys, subkeys, and values rooted at the top level of the registry hierarchy.
| Note | As with Windows NT/2000, Windows XP/Windows Server 2003 registry also resides on the disk in the form of multiple files called hives, serving as a repository for system configuration data. The registry code has been redesigned for Windows XP and Windows Server 2003, providing enhanced performance, while remaining transparent to applications by using existing registry programming interfaces. Windows XP and Windows Server 2003 registry enhancements are mainly intended to provide performance improvements and will be covered in more detail later in this chapter. |
Registry hive data is stored physically in disk files, which in turn are stored in %SystemRoot%\System32\Config and %SystemRoot%\Profiles\Username folders (Windows NT 4.0). Windows 2000, Windows XP, and Windows Server 2003 store registry hives in %SystemRoot%\System32\Config and %SystemDrive%\Documents and Settings\Username folders.
At first glance, it might seem that each root key seen while running one of the registry editors is a separate hive. However, this relationship isn't that simple and straightforward. In fact, none of the root keys represent physical hives. Actually, the Configuration Manager - the kernel subsystem that implements the registry-links hives together, creates the root keys and builds the familiar registry structure displayed by registry editors.
Each physical registry hive is associated with a set of standard supporting files. Table 1.3 lists standard registry hives, existing in Windows NT/2000, Windows XP, and Windows Server 2003 together with supporting files.
|
| Registry hive | Supporting files |
|---|---|
| | |
| HKEY_LOCAL_MACHINE\SAM | Sam, Sam.log, Sam.sav |
| HKEY_LOCAL_MACHINE\Security | Security, Security.log, Security.sav |
| HKEY_LOCAL_MACHINE\Software | Software, Software.log, Software.sav |
| HKEY_LOCAL_MACHINE\System | System, System.alt[*], System.log, System.sav |
| HKEY_CURRENT_CONFIG | System, System.alt[*], System.log, System.sav |
| HKEY_USERS\.DEFAULT | Default, Default.log, Default.sav |
| HKEY_USERS\User_SID | %SystemDrive%\Documents and Settings\ |
| HKEY_CURRENT_USER | Username\Ntuser.dat, %SystemDrive%\Documents and Settings\ Username\Ntuser.dat.log |
| HKEY_USERS\User_SID_Classes | %SystemDrive%\Documents and Settings\ Username\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat and % SystemDrive%\Documents and Settings\ Username\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat.log |
| (Files that aren't associated with keys) | Userdiff, Userdiff.log, Userdifr[**], Userdifr.log[**] |
|
[*]Files that were eliminated starting with Windows XP
[**]Files that were first introduced in Windows XP | |
|
| Note | As you can see from this table, some registry files were eliminated with the introduction of the Windows XP and products of the Windows Server 2003 family, while other files were introduced for the first time. This is due to the registry enhancements implemented in Windows XP and Windows Server 2003, which will be covered in more detail later in this book. Also note the difference between HKEY_USERS\User_SID, HKEY_USERS\User_SID_Classes and HKEY_CURRENT_USER keys and their respective hives. HKU\User_SID and HKU\User_SID_Classes are hive files containing user-specific settings. The HKU\User_SID data corresponds to the Ntuser.dat and Ntuser.dat.log files stored under %SystemDrive%\Documents and Settings\Username, while UsrClass.dat and UsrClass.dat.log hives support data under the HKEY_USERS\User_SID_Classes registry keys. This separation was first introduced with Windows 2000, in order to support roaming user profiles. If the user has a roaming profile, Windows 2000/XP and products of the Windows Server 2003 family synchronize the Ntuser.dat file with the copy of the user profile stored on network server. On the other hand, the UsrClass.dat file isn't subject to this synchronization (more information on this topic will be provided in Chapter 10). |
The main difference between physical registry hives and other groups of registry keys is that physical hives are constant registry components. Physical hives aren't created dynamically when the system boots and aren't deleted when someone shuts the system down. However, besides physical hives, there are other important registry structures created and managed entirely in memory - for example, the HKEY_LOCAL_MACHINE\Hardware key, which is created dynamically by the hardware recognizer when the system boots. This key stores information related to physical devices and their assigned resources. Since hardware detection and resource assignment take place during each system boot, it is quite logical not to store this information on disk. Thus, the HKEY_LOCAL_MACHINE\Hardware key can't be considered a physical hive. Sometimes, such registry structures are referenced as volatile hives.
All hive files, except for HKEY_CURRENT_USER, are stored in the %SystemRoot%\System32\Config folder.
The HKEY_CURRENT_USER hive is supported by Ntuser.dat and Ntuser.dat.log files. Ntuser.dat files contain user profiles, while Ntuser.dat.log files reflect all of the changes introduced to Ntuser.dat file. Windows NT 4.0 stores these files in subfolders of the %SystemRoot%\Profiles folder (except for the \All Users subfolder). Windows 2000 and its successors store these files in %SystemDrive%\Documents and Settings\%Username% folders.
There are four types of files associated with registry hives. All of these file types, with the appropriate filename extensions, are listed in Table 1.4.
|
| Filename extension | Description |
|---|---|
| | |
| None | Contains the registry hive copy. |
| ALT[*] | In Windows NT/2000, the ALT files contain the backup copy of the HKEY_LOCAL_MACHINE\System hive. The System hive is the only hive that has this type of backup copy stored in the System.alt file. As was already mentioned, ALT files were eliminated in Windows XP and Windows Server 2003 because the registry code was redesigned to provide improved algorithms for faster queries, improved reliability, and larger registries. |
| LOG | Contains the transaction log. Any changes introduced to the keys and values make up this hive. |
| SAV | Contains copies of registry hive files from the time the text-mode part of the installation process was accomplished. There are SAV files for the following registry hives: \Software, \System, \SAM, \Security, and \Default. Windows NT/2000, Windows XP, and Windows Server 2003 make backup copies of the registry hives during the installation process. The installation procedure consists of two parts; namely, the text-mode and the GUI-mode part of the installation. When the text-mode part of installation procedure is complete, the Setup program backs up the registry hives to the SAV files. This is done to protect the hives from failures, which may occur during the GUI-mode part of setup. If such a failure occurs, the GUI-mode setup will resume after reboot, and SAV files will be used for rebuilding the registry hives. |
|
[*]Files that were excluded from Windows XP and Windows Server 2003 | |
|
Hive Atomicity and Recovery
The registry ensures the atomic nature of individual operations. This means that any modifications made to a registry value (resetting, deleting, or saving) either work or don't work. This mechanism eliminates corrupt combinations of old and new registry values, in case the system stops unexpectedly due to a power failure, a hardware malfunction, or problems with the software. Consider, for example, the case where an application sets a value and the system shuts down unexpectedly while this change is being made. After rebooting the system, this registry entry will either be reset to its previous value or have a new value, but no meaningless combinations of both registry parameters will appear. Moreover, the size and time data for the key containing the affected value will be accurate, whether this value has been changed or not.
Flushing Data
Windows NT-based operating systems save registry data only after a flush occurs. Data flush occurs only after the modified data ages past a few seconds. Furthermore, data flush can be initiated by a direct call from the application, which intentionally flushes its data to the hard disk.
The system performs the following flushing procedure:
-
All changed data are saved to the LOG file of the respective hive, together with information on the exact location of the changed data within a hive. When this is done, the system performs a flush, and all modified data are written to the LOG file.
-
The first sector of the hive file is marked, which means that this file is in a transitional state.
-
The modified data are written to the hive file.
-
Finally, this hive file is marked as completed.
| Note | If the system shuts down unexpectedly while performing this procedure (between steps 2 and 4), it will recover the affected hive. When this hive is loaded during system startup (except for user profile hives, which are loaded when the user logs on to the system), the system will note the marker left in step 2 and it will continue recovering the hive using the changed data saved to the LOG file. Thus, if the hive wasn't in transition, its LOG files aren't used. If the hive was in transition when the system stopped, it can't be loaded without a respective LOG file. |
The \System hive is vitally important and is used at the earliest stages of the system boot. This hive includes the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control key, which contains information necessary for initializing the registry during the boot process. For example, registry entries stored with the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hivelist specify the location of all other registry hives. Thus, if the \System hive is missing or corrupt, it can't be recovered using the procedure described above. Because of this, Windows 2000 and earlier versions use a different flushing process for the hive.
The System.alt file contains a copy of the System hive data. During the flush process, all changes are marked, saved, and then marked as completed. After this process is completed, the same flush process is done for the System.alt file. If there is a power failure, hardware malfunction, or a problem with the software that causes a system shutdown at any stage of this process, the system will try to find the correct information in either the System file or the System.alt file.
The System.alt file is similar to the LOG file, except that, during a boot, the system will switch to using the System.alt file instead of trying to reapply all the changes saved in the LOG file. If the System file isn't marked as being in transition, then System.alt won't be needed.
| Note | Windows XP and Windows Server 2003 solve this problem by moving the registry out of the paged pool and using the cache manager to carry out an in-house management of the registry. Therefore, there is no need to use the System.alt file in Windows XP and Windows Server 2003. |
Registry-Size Problem
When we discussed the drawbacks of INI files earlier in this chapter, we mentioned the problems caused by the Win.ini size limitation. The Windows NT/2000 registry seemed to solve this problem, but it still remained limited in size. At the same time, there was a steady trend among registry consumers to use the registry like a database, which constantly increased the demands made on registry size. The original design of the registry kept all of the registry files in the paged pool, which, in the 32-bit kernel, is effectively limited to approximately 160 MB because of the layout of the kernel virtual address space. A problem arose because, as larger registry consumers such as Terminal Services and COM appeared, a considerable amount of paged-pool was used for the registry alone, potentially leaving too little memory for other kernel-mode components.
Registry Size Limit in Windows NT/2000
To solve the problem described above, Windows NT 4.0/Windows 2000 allows for the restriction of the size to which the registry can grow. To set the registry size limitation in Windows 2000, use the following procedure:
-
Double-click on System in the Control Panel window. The System Properties window will appear.
-
Go to the Advanced tab and click on the Performance Options button to open the Performance Options window (Fig. 1.8). Click on the Change button in the Virtual Memory group of options. The Virtual Memory window will appear (Fig. 1.9). At the bottom of this window is the Registry size group with the Maximum registry size (MB) field, allowing the user manually to set the maximum registry size.
Figure 1.8: The Performance Options window
Figure 1.9: Setting the registry size limitation for Windows 2000
Windows NT/2000 registry data loaded to the memory are stored in a paged pool, which is a region in the physical memory used for storing data that can be flushed to the hard disk if not used for a long time. The size limit on the registry is set to prevent the situation where the registry consumes all of the space required by other processes.
Registry Enhancements in Windows XP and Windows Server 2003
In contrast to Windows NT/2000, in Windows XP and products of the Windows Server 2003 family, the registry size limitation has been removed. The registry code has been redesigned to provide enhanced performance, while remaining transparent to applications by using existing registry programming interfaces.
The new registry implementation delivers two key benefits:
-
Larger registries
-
Faster queries
Therefore, neither Windows XP nor Windows Server 2003 provide the user with the option to establish a registry size limit (Fig. 1.10).
Figure 1.10: In Windows XP and Windows Server 2003, there is no option for setting the registry size limitation
Thus, in contrast to Windows NT/2000, where you can use the System applet in Control Panel to view the current registry size, Windows XP and Windows Server 2003 don't provide you with this option. However, to discover how much data is actually stored in your registry, you can use the Dureg.exe Resource Kit utility, which can be downloaded from http://download.microsoft.com/download/win2000platform/WebPacks/1.00.0.1/Nt5/EN-US/Dureg.exe. Although this commandline tool is part of Windows 2000 Server Resource Kit, it also works fine with Windows Server 2003. Besides estimation of the amount of data stored in the whole registry, this tool allows you to discover how much data is stored in any registry subtree, key, or subkey, and also enables you to search for all occurrences of a text string in the registry.
The Dureg.exe utility uses the following syntax:
dureg [{/cr | /cu | /u | /lm | /a}] [{/s | /d}] [registry_path] [string to search], where:
-
/a-this option will calculate the size of the entire registry.
-
/cr registry_path - this option will evaluate the size of the HKEY_CLASSES_ROOT root key. To evaluate the size of specific subkey within this key, it is necessary to specify a registry path (registry_path parameter).
-
/cu registry_path - this option will evaluate the size of the HKEY_CURRENT_USER root key. Include a registry path to calculate the size of any subkey within this subtree.
-
/lm registry_path - calculates the size of HKEY_LOCAL_MACHINE root key. To evaluate the size of any subkey within this subtree, specify the path to that key (registry_path).
-
/u registry_path - this option will calculate the size of HKEY_USERS root key. Include a registry path to find the size of any key within this subtree.
-
/s string - use this option to find any text string within the registry.
| Note | The Dureg.exe utility counts data, not space. Because the space any data occupy varies with the storage method and amount of free space available, the size of data and size of space consumed are not equal. Also, Dureg.exe does not account for fragmented free space in the registry. |
Let us consider the registry enhancements mentioned above in more detail.
-
Larger Registries. Windows XP and products of the Windows Server 2003 family support larger registries than previous versions of the kernel, which were effectively limited to about 80 percent of the total size of the paged pool. The new implementation is limited only by the available system disk space. This problem was solved by moving the registry out of the paged pool and using the cache manager to carry out the management of the mapped views of the registry files. The mapped views are mapped in 256K chunks into system cache space instead of into the paged pool.
-
Faster Queries. Another issue that affected registry performance in earlier versions was the locality problem. Related cells are spread through all of the registry files. Accessing certain information, such as attributes of a key, could degenerate into page-faults, which lower performance. In Windows XP and Windows Server 2003, the registry uses an improved algorithm for allocating new cells that keeps related cells in closer proximity - for instance, keeping cells on the same page or nearby pages which solves the locality problem and reduces the page faults incurred when accessing related cells. A new hive structure member tracks freed cells instead of relying on linked freed cells. When future cells are allocated, the freed cell list and a vicinity argument are used to ensure that they are put in the same bin as the hive.
Windows XP and products of the Windows Server 2003 family improve the way the registry handles large data. In earlier versions, prior to Windows XP and Windows Server 2003, if an inefficient application increased a value steadily by small increments, it created a sparse and wasteful registry file. Newer versions of the Microsoft Windows operating systems solve this problem with a large cell implementation, where cells larger than 16K are split into increments of 16K chunks. This reduces fragmentation when the data length of a value is increased within a certain threshold.
|
|
