Inside the Registry

The Registry is the centralized configuration database for Windows NT and Windows 2000 (Win2K), as well as for applications. The Registry stores information about tuning parameters, device configuration, and user preferences. Many books and articles can help you learn about the logical layout of the Registry. These resources describe where the Registry stores specific configuration settings, which values the settings can store, and what happens when you change the settings.

However, these resources don't describe how NT physically manages the Registry. In other words, how do NT and Win2K organize the Registry on disk, how do these OSs locate and retrieve configuration information when an application requests this information, and what measures do they employ to protect this database that's so crucial to their operation?

This month, I'll show you how the Configuration Manager—the kernel subsystem that implements the Registry—organizes the Registry's on-disk files. I'll discuss how the Configuration Manager manages the Registry as applications and other OS components read and change Registry keys and values. Finally, I'll discuss the mechanisms by which the Configuration Manager tries to ensure that the Registry is always in a recoverable state, even if the system crashes while you're modifying the Registry. To get the most from this column, you need to be familiar with the Registry's logical organization, including the concepts of root key, subkey, and values. If you don't have such knowledge, I recommend that you first read "Inside the Windows NT Registry," April 1997.

Hives
On disk, the Registry isn't simply one large file but a set of discrete files called hives. Each hive contains a Registry tree, which has a key that serves as the root (i.e., starting point) of the tree. Subkeys and their values reside beneath the root. You might think that NT stores each root key you see when you run one of the Registry editors (regedit or regedt32) in a separate hive, but such is not the case. The correlation between the keys that regedit displays and the content of the hives isn't straightforward, as Table 1, page 68, shows. In fact, none of the root keys correlate to hives. Table 2, page 68, lists Registry hives and their on-diskfilenames. Note that the names don't have extensions. The absence of corresponding files signifies that logical root keys are objects with no on-disk representation. The Configuration Manager creates the root keys, linking hives together to build the Registry structure you are familiar with and that regedit displays.

When you look at Tables 1 and 2, you'll see that some hives are volatile and don't have associated files. The system creates and manages these hives entirely in memory; the hives are therefore temporary in nature. The system creates volatile hives every time the system boots. An example of a volatile hive is the HKEY_LOCAL_MACHINE\HARDWARE hive, which stores information regarding physical devices and the devices' assigned resources. Resource assignment and hardware detection occur every time the system boots, so not storing this data on disk is logical.

The heart of the Registry is the HKEY_LOCAL_MACHINE\SYSTEM hive. In particular, this hive's subkey \CurrentControlSet\Control contains settings that the Configuration Manager uses to initialize the Registry. When the Configuration Manager is initializing hives and needs to locate the hives' files, the Configuration Manager refers to the value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hivelist.

A special type of key known as a symbolic link makes it possible for the Configuration Manager to link hives to organize the Registry. A symbolic link is a key that redirects the Configuration Manager to another key. Thus, the key HKEY_LOCAL_MACHINE\SAM is a symbolic link to the key at the root of the SAM hive.