Understanding the Registry s Structure

[Previous] [Next]

In a file system, the root objects are disks, which contain folders and files. A single folder can contain an arbitrary number of other folders and files; each folder or file has a name. By combining the names of the folders that enclose a file, we can construct a path that unambiguously names only one file on the disk, so that C:\Windows\Mapi32.dll and C:\Winnt\Mapi32.dll are completely separate files, for example.

The Windows 2000 registry is organized much like a file system, except that the vocabulary needed to describe it is somewhat different. At the root of the registry structure are the root keys (likened to a disk in a file system). Each root key contains several subkeys (folders); in turn, these subkeys contain other subkeys and values (the registry equivalent of files). Like files, each value has a name that must be unique in the subkey or folder that encloses it; each value also has an associated data type that governs what kind of data it can hold.

Any registry value can be identified by specifying its full path, starting at the root. For example, the path HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Security\ObscureWireDataFormat specifies a particular value in the Security subkey that belongs to Microsoft Exchange Server. Figure 36-1 shows an annotated section of the Windows 2000 registry so that you can identify the root keys, subkeys, and values in it.

Figure 36-1. The three separate components of a registry value.

The Root Keys

When you open the My Computer icon on your desktop, you always see certain items, such as icons that represent the logical disk volumes on your computer. The same is true of the registry. When you open it with a Registry Editor, you'll always see the same set of root keys. Each root key has a distinct purpose:

• HKEY_LOCAL_MACHINE (HKLM) stores all settings that pertain to the local machine. For example, the HARDWARE subkey of HKLM is where the system and its device drivers record and share information about the hardware devices that the system finds at boot time (as well as other Plug-and-Play devices that you can add after the system is booted). Applications are supposed to store data here only if it pertains to everyone who uses a machine; for example, a printer driver might store a set of default print settings here and copy them to each new user's profile when he or she logs on.
• HKEY_USERS (HKU) contains one entry for each user who has previously logged on to your computer. Each user's entry is owned by that user's account, and it contains the profile settings that were in effect for that user. When you use group policies (see Chapter 9), the policy settings you specify are applied to an individual user's profile here.
• HKEY_CURRENT_CONFIG (HKCC) stores information about the system's current boot configuration. In particular, it contains information about the current set of system services and which devices were present at boot time. This root key is actually a pointer to sections inside HKLM.
• HKEY_CURRENT_USER (HKCU) points to the currently logged on user's profile inside HKU. Microsoft requires that Windows 2000 applications store any user-specific preferences in subkeys under HKCU; for example, HKCU\SOFTWARE\Binary Research\GhostSrv\Settings holds a user's personal preferences for Symantec's Ghost product. Another user's settings for the same product would be available in the same key only when that user is logged on.
• HKEY_CLASSES_ROOT (HKCR) ties file extensions and OLE class identifiers together; it actually points to HKLM\SOFTWARE\Classes. System components like Windows Explorer (and Microsoft Internet Explorer, for that matter) use these associations to determine which applications or components to use when opening or creating a particular type of file or data object. Since Windows 2000 relies heavily on the Component Object Model (COM), which in turn relies on the object identifiers stored in HKCR, this key and its subkeys are more important than you might think at first.

NOTE

---

In the Windows 2000 documentation, Microsoft identifies only two registry root keys: HKLM and HKU. Since HKCU, HKCC, and HKCR are actually pointers to subkeys of HKLM and HKU, this is technically correct, but you might be confused if you're used to the idea of five separate root keys. To avoid that confusion, we'll use the old-style notation.

REAL WORLD  HKCR in Windows 2000

---

One important registry change in Windows 2000 involves HKCR. In Windows NT 4 and earlier, the data in HKCR is the same for all users. In some ways, this was a reasonable design decision for Microsoft to make—all users on the machine have access to the same set of installed OLE components and file mappings.

However, one common complaint from administrators whose users have to share machines is that two users' preferred associations might differ. If one user chooses Netscape Navigator as the preferred Web browser, that modifies HKCR; if another user later sets Internet Explorer as the preferred browser at the same machine, that undermines the original choice. More importantly, the ability for users to change these values reduces system security in two ways: it allows users to change associations for other users (increasing the risk of introducing malicious code), and it forces administrators to remove permissions from HKLM\SOFTWARE\Classes, since all users need access to it.

In Windows 2000, Microsoft changed this behavior so that HKCR actually contains data from two sources: the user's profile (where user-specific customizations are stored) and HKLM\SOFTWARE\Classes, where systemwide settings live. Users can register and unregister COM components, change file associations, and so on without affecting other users, and you can adjust permissions on HKLM\SOFTWARE\Classes so users can't tamper with the systemwide settings you want them to have. Each user's unique settings are stored in the Usrclass.dat file, which is treated like its own registry hive. (See "Where Data Goes on Disk" later in the chapter for more details on hive files.)

Major Subkeys

Within these root keys, several subkeys are noteworthy. Because each root key has so much information under it, you'll usually hear these individual subkeys referred to—after all, HKLM\HARDWARE and HKLM\SOFTWARE don't have much in common except their root key.

HKLM\HARDWARE

The HKLM\HARDWARE subkey stores information about the hardware found in the system. All of the values stored here are held only in RAM, not on disk, because of the device driver ordering problem mentioned earlier. When the hardware recognizer starts, it enumerates every device it can find, both by walking the system buses and by searching for specific classes of devices like parallel ports or keyboards. Three major subkeys live under HKLM\HARDWARE:

• The DESCRIPTION subkey contains descriptions of the CPUs, floating-point processors, and multifunction devices in the system. The information stored here is considerably expanded over what is available in Windows NT 4; for example, the CentralProcessor subkey now tracks a number of settings that aren't present in Windows NT 4. For computers that use multipurpose chipsets like Intel's BX series, one of the multifunction devices listed in this key will reflect the chipset's integrated controllers, with separate entries for disk, keyboard, pointer, parallel, and serial controllers.
• The DEVICEMAP subkey links a specific device to a specific driver. For example, DEVICEMAP\Video has a value named \Device\Video1 that contains the string \REGISTRY\Machine\SYSTEM\ControlSet001\Services\mnmdd\Device0, which is a pointer to the place where the driver for that video controller stores its parameters.
• The RESOURCEMAP subkey exists in Windows NT 4, but it is completely revamped in Windows 2000. It now contains three primary subkeys: one for the hardware abstraction layer (HAL) to use when keeping track of the devices it finds, one for the Plug-and-Play Manager to record devices it knows how to handle, and one that reflects the amount of system resources (Microsoft-speak for RAM) available on the machine.

Additional subkeys can exist, depending on the configuration of your machine. For example, systems that support the Advanced Configuration Power Interface (ACPI) will have an ACPI subkey that contains information about the specific ACPI subfeatures that the computer supports.

HKLM\SAM

Just because Windows 2000 includes the Active Directory directory service, don't assume that no vestiges of the Security Accounts Manager (SAM) have survived. When you create local accounts or groups on a Windows 2000 machine, they are stored in HKLM\SAM, just as they are in Windows NT. However, you can't normally view or change data in this subkey, and it is mostly useful for compatibility with earlier Windows NT code that expects SAM to exist. The programming routines that access SAM data have all been revamped to use Active Directory data when it exists, or SAM when no Active Directory server is present.

HKLM\SECURITY

HKLM\SECURITY contains a lot of security information, as you might expect. Its format isn't documented, and you can't do anything in the subkey. However, the system caches logon credentials, policy settings, and shared server secrets in this subkey. The SECURITY\SAM subkey contains a copy of most of the data from HKLM\SAM.

REAL WORLD  Look, but Don't Touch!

---

If you're feeling adventurous and want to see what's in HKLM\SAM and HKLM\SECURITY, you can open these keys by running Regedt32 in the LocalSystem security context. The easiest way to do this is to use the At command to schedule Regedt32 to run in an interactive session. Just schedule it to run a minute or so into the future, like this:

at 12:34 /interactive regedt32.exe

That command tells the system to schedule Regedt32 to run one minute from now (this being written at 12:33); when it runs, the system scheduler service will launch the application, so it runs in the LocalSystem context instead of the context you're logged on as. While this is an interesting way to see what's in these subkeys, be forewarned of two things. First, you won't be able to make much sense out of the values in these keys, since they're intentionally obfuscated. Second, and more importantly, remember that changing any of these values will provoke unintended and probably undesirable consequences. In other words, look, but don't touch.

HKLM\SOFTWARE

The HKLM\SOFTWARE subkey serves as the root location for applications and system components to store their machine-wide settings. For example, HKLM\SOFTWARE\Microsoft\EnterpriseCertificates contains keys that hold the certificate trust lists (CTLs) and trusted CA certificates for this machine—individual users' CTLs and trusted CAs are stored elsewhere. Individual programs, control panels, and the like can create their own subkeys under HKLM\SOFTWARE; the de facto standard is for each vendor to create its own top-level key (for example, HKLM\SOFTWARE\Intel) and then create subentries beneath that key.

The most interesting parts of this subkey are HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion (which stores much of the GUI preference data; it's named the same as the corresponding key under Windows 95/98) and HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion. This latter subkey is significantly expanded in Windows 2000; for example, there are new keys for automatic server recovery handling, the Encrypting File System, the Security Configuration Editor, Terminal Services, and other new goodies.

HKLM\SYSTEM\CurrentControlSet

When you boot Windows 2000, the last action in the boot phase is to update the registry to reflect which set of controls and services was last used for a successful boot. CurrentControlSet always points to the set of controls actually in use on the system. If you look under HKLM\SYSTEM, you'll see many ControlSetXXX keys. Each ControlSetXXX subkey represents a control set that existed at one time, whether or not it was successfully used to boot. CurrentControlSet is just a pointer to the most recent successful boot set, but because it isn't easy to determine which set that was, the OS and applications use CurrentControlSet instead.

Beneath this set are four keys whose names carry over from earlier versions of Windows NT, although their guts are somewhat different in Windows 2000:

• Control Contains control information for services and system tools. For example, Control\BackupRestore\KeysNotToRestore contains a list of keys that Windows 2000 Backup shouldn't restore (including the contents of the Plug-and-Play subkey) when it restores the registry.
• Enum Contains one entry for every physical device or pseudo-device that the system can find. For example, Enum\USB\Vid_0461&Pid_4d03\Inst_0 contains information about the USB mouse plugged in to someone's laptop. Since it was present at boot time, it is included in the enumeration list.
• Hardware Profiles Contains one entry for each hardware profile defined on a machine. As with HKLM\SYSTEM itself, each profile has a serial number, starting with 0001. HKLM\SYSTEM\Hardware Profiles\Current always points to the profile that was selected at boot time.
• Services Contains one subkey for each installed service. These subkeys, in turn, hold all the configuration information that the service needs. The exact set of subkeys on two machines will be different if they have different services loaded on them.

HKLM\SYSTEM\MountedDevices

Windows 2000 dynamic disk volumes (discussed in Chapter 14) are a neat technical achievement and a boon to administrators, but they depend on having information about the current configuration of the logical volumes on disk. Applications (and snap-ins, like the Disk Management snap-in) get this information from the Logical Volume Manager service; in turn, this service stores its list of mounted and available devices in the MountedDevices subkey.

How Data Is Stored

Although programs and services that use the registry don't have to understand how registry data is stored, administrators do—that way you'll know where data is stored, how the registry handles different types of data, and which files need to be safeguarded as part of your backups. You don't need to understand the internal format that the registry tools use, but you should understand the basic data types and storage locations.

Each value in the registry (Microsoft calls them value entries) has three parts: a name, a data type, and an actual value. For example, if you see a Microsoft Knowledge Base article that talks about some key—\REG_SZ:HKLM\SYSTEM\CurrentControlSet\Services\Replicator\Parameters\GuardTime, for example—you're seeing a complete definition of a value entry (although it's always nice to see a full path for values, so you know where to add or remove them).

Useful Data Types

Seven data types can be used to store data in the registry. Actually, only two of these types are used for most registry data: REG_DWORD and REG_SZ. The seven types are as follows:

• REG_BINARY stores arbitrary binary data in raw form, without any reformatting or parsing. You can view binary data in binary or hex forms by using one of the Windows 2000 registry editors (described later in the chapter).
• REG_DWORD stores an 8-byte long integer (or double word) value. This data type is usually used when a value indicates a count or interval, but it's also common to see REG_DWORD flags—0 means the flag is off, and 1 means it's on.
• REG_SZ is an ordinary Unicode string. These strings can be of any length; this data type is usually used to store paths, human-readable messages or device names, and so on.
• REG_EXPAND_SZ is a REG_SZ with a twist—applications can embed a special token in the string and then expand the token when they read the value from the registry. For example, Something is a REG_EXPAND_SZ whose normal value is %SystemRoot%\System32\Something. When Windows 2000 reads the string, it expands %SystemRoot% to the full path where the operating system is installed.
• REG_MULTI_SZ is a collection of an arbitrary number of REG_SZ values. For example, the list of DNS servers you specify in the TCP/IP Properties dialog box is stored in a REG_MULTI_SZ value. Applications must know how to pick apart a single REG_MULTI_SZ into its component parts.
• REG_FULL_RESOURCE_DESCRIPTOR is a rare bird; it is used to encode information about the system resources required by a particular device. We've never seen it appear outside of subkeys of HKLM\HARDWARE.
• REG_NONE is just a placeholder. It is used to indicate that a registry value exists but doesn't contain any actual data. Some components look for the presence or absence of a specified key or value to control their behavior at runtime; it's common for those components to look for an item of type REG_NONE—since this type doesn't hold any data, users can't mess these values up.

In day-to-day administration, what you'll need to know about these data types is mostly restricted to understanding the difference between REG_DWORD and REG_SZ values. A REG_DWORD value whose contents are 0 (the numeric value for zero) is different from a REG_SZ whose contents are "0" (the character "0"). If you need to add a new registry value (perhaps because a Microsoft Knowledge Base article recommends doing so), you'll have to ensure that you get the type right, or you might have problems with the components that use the value.

Volatile Keys

Some registry keys and values are volatile, in the original sense of the word—they aren't persistent and can evaporate at any moment. As an example, none of the data in HKLM\HARDWARE exists anywhere on disk; that entire subkey and all its contents reside entirely in memory. Every time you boot a Windows 2000 machine, that subkey is created anew, and when you shut it down, its contents disappear.

Disk-Based Keys

Volatile keys are useful for data that doesn't need to stay around between reboots, but most of the data stored in the registry would be pretty useless if it weren't persistent. Imagine having to reconfigure all your preferences and settings after every reboot of your desktop machine—that would get old fast. The majority of registry keys are disk-based, meaning that their contents are held in structures on disk. When a key's contents are updated, the version on disk is updated too.

Even though disk-based keys are eventually stored on disk, Windows 2000 maps them into the paged memory pool (an area of memory whose contents can be written to the pagefile when not being used) to provide more efficient access. The registry size limit, discussed later in this chapter, regulates how much registry data can be stored in the paged pool.

Where Data Goes on Disk

Microsoft uses the term "hive" to refer to a group of keys and values that belong together. A hive can be a root key, or it can be a subkey; for example, HKCC is a hive (even though it's just a pointer to part of HKLM), and so is HKLM\SAM. The important concept to remember about hives is that a hive is a self-contained unit that can be loaded and unloaded independently of other hives.

Windows 2000 uses six hives: DEFAULT (corresponding to HKU\.DEFAULT), SAM (HKLM\SAM), SECURITY (HKLM\SECURITY), SOFTWARE (HKLM\SOFTWARE), and SYSTEM (HKLM\SYSTEM). The sixth hive, which corresponds to the contents of HKCU, is better known as a user profile—a user profile is really just a hive that is loaded into the registry when the user logs on and unloaded at logout.

Each hive exists in its own file on disk (the files have the same names as the hives), along with a separate log file that acts as a journal of all changes made to that hive. Hive files don't have extensions, and the system keeps them open all the time—that's why you have to use a special-purpose backup tool like Windows 2000 Backup or ARCServe to back them up.

So, where do these hive files live? As with so many other Windows 2000-related questions, the answer is a hearty "It depends." In this case, the answer depends on which hives you're talking about. The big five (DEFAULT, SAM, SECURITY, SOFTWARE, and SYSTEM), along with their .LOG files, are stored in the System32\Config subfolder of the Windows 2000 Install folder.

The location of the user profile files (Ntuser.dat and Ntuser.dat.log for the logged-on user, Default and Default.log for the default user) depends on which operating system was on the machine before Windows 2000. Machines that were upgraded from Windows NT 4, or those on which Windows 2000 was cleanly installed, keep these profiles in the Profiles\Username subfolder of the system root folder. (Each user has his or her own subfolder.) For machines that were upgraded from Windows 95 or Windows 98, profiles are stored in a folder named for the user in the system's Documents and Settings folder.