2.2 What Goes in the Registry

No two snowflakes are alike. It's not quite true to say that no two Registries are alike, but they can vary significantly from machine to machine. There's a standard set of keys Windows 2000 uses, but even this standard set varies somewhat, depending on whether the computer's running Windows 2000 Professional or a member of the Windows 2000 Server family, what optional components are installed, and how the machine's network connection is configured.

The Registry help files included with the Windows 2000 Resource Kit (as well as the material in Chapter 11 ) explain what individual keys are for, but using that data to grasp what's important is like trying to build a watch out of a bag full of parts; it's much more instructive to examine a working watch and see how its parts relate. To provide a working watch for your entertainment, this section examines the most important subkeys of the root keys described earlier in this chapter.

2.2.1 Major Subkeys of HKLM

HKLM 's purpose is to store all the important configuration data for the local machine. It doesn't contain any information about other machines on the network or about user-specific configuration data; instead, it's nothing but settings for the machine where it's stored. HKLM has four important subkeys.

2.2.1.1 HARDWARE

All the keys and subkeys of HKLM\HARDWARE are generated by Windows 2000 at boot time and exist only in memory; they aren't stored on disk. This may seem odd, but when you consider the Windows 2000 boot process, it makes more sense. The boot loader (NTLDR.COM ) is loaded by the standard DOS boot mechanism. When it executes, it loads and starts the Windows 2000 kernel. The kernel in turn must first start up the hardware abstraction layer; the HAL provides a buffer between the gory details of hardware resources and the neatly structured system of device drivers the operating system uses to talk to hardware. For this approach to work, the HAL must register the hardware it finds, but at the time it finds those devices, it may not have found any disks to register the data on! Keeping the hardware keys in memory nicely solves this problem.

There are four subkeys of HKLM\HARDWARE. For the most part, your interaction with them will be very limited, especially since you can't change them. All the information you might gain by manually inspecting these subkeys is more easily available through the System Properties dialog box. Having said that, though, here they are:

DESCRIPTION: This subkey keeps track of which hardware devices are present. During the boot phase, the hardware-detection software creates entries under this key for every hardware device it can find. Note that it keeps track of ports, not devices on those ports; it will find a parallel printer port, but doesn't check to see what's attached to it. Disk controllers are an exception to this rule.
DEVICEMAP: DEVICEMAP links the list of which devices are present and the drivers that make them available to the system. Each driver starts up and attempts to take control of whatever device it controls. If the driver succeeds, it registers its ownership of the device in DEVICEMAP. This isn't much different from the human process of registering car titles at the county courthouse.
OWNERMAP: This subkey ties bus devices to particular system buses. Many machines support multiple buses; e.g., PCI, ISA, EISA, or VLBus controllers can all coexist on a single machine. OWNERMAP registers which installed cards are attached to which buses.
RESOURCEMAP: As its name strongly suggests, RESOURCEMAP provides a map of what resources are available. To be more specific, it lists the IRQs, DMA port addresses, and bus controller slots supported by the hardware. Drivers choose from this list to reserve the resources they need; as they successfully claim hardware, they register which resources they're using here so other drivers won't try to use them too. The actual contents of this key are much different in Windows 2000 than in Windows NT; the 2000-specific version includes a new subkey for the Plug and Play manager.

2.2.1.2 SECURITY

The SECURITY subkey holds two important collections of data. First off, it caches the local copy of the Security Account Manager database in HKLM\SECURITY\ SAM. This database is the foundation of all the system's access controls. Besides ACLs for every object that has permissions assigned to it, this subkey contains a roster of local or domain accounts and groups, since the ACLs grant permissions to groups and users. This subkey actually maps to a separate hive, and its data is normally readable only by kernel services that have the appropriate "need to know." The SAM data has been kept here since Windows NT 3.1 first shipped, although in Windows 2000 it's kept here only for backward compatibility and to support machines that aren't part of an Active Directory domain.

As you learned in User Profiles Demystified, NT 4.0 adds the capability to use user and group policies. These policies also live in subkeys of HKLM\SECURITY. These policies control what users can and can't do on the machine, ranging from small things like changing the desktop wallpaper to big things like rebooting servers or editing the Registry. The data in the SAM is encrypted, so you can't directly access or modify it. Instead, you need to use the System Policy Editor (as described in Chapter 6) to set profiles, which NT then loads automatically into this subkey when they're needed.

Not even the Administratoraccount has permission to open these subkeys. Even if you change the ownership rights on SECURITY or its hive so that your account can open it, you'll find that the data there is encrypted. Even if you manage to decrypt it, the data is in an undocumented format that probably won't do you any good. Don't despair, though: there are functions in the Win32 API you can use to create, read, and change security descriptors, permissions, and policies.

The HKLM\SAM subkey just points to HKLM\SECURITY\SAM ; it's provided as a convenience for parts of the kernel that need access to the SAM data.

2.2.1.3 SOFTWARE

Applications and system components store their settings under subkeys of SOFTWARE. By convention, programs that keep things here are supposed to create subkeys using the program and/or vendor name, then put their settings underneath. HKLM\SOFTWARE\TechSmith\Snagit32 thus contains settings for TechSmith's SnagIt/32 screen-capture utility. Most of the operating-system components keep their systemwide settings under HKLM\SOFTWARE\ Microsoft\ComponentName. Settings that belong only to a single user are stored elsewhere. The exact contents of this subkey vary from machine to machine, depending on what software's installed. My best estimate is that about 80% of the time you spend viewing or editing the Registry will be spent in various subkeys of HKLM\SOFTWARE.

In particular, HKLM\Software\Microsoft\Windows NT holds most of the specific software configuration settings. In addition, there's a counterpart key named HKLM\Software\Microsoft\Windows that provides an equivalent to the Win95 key with the same name. The Windows 2000 shell (which, of course, is largely based on the Windows NT 4 shell's code) makes heavy use of this key for tracking where applications are installed and how they can be uninstalled when needed.

2.2.1.3.1 SOFTWARE\Policies

Group policy objects can store their settings in four distinct keys, three of which are under HKLM. Policy settings that are new for Windows 2000 (say, for instance, the setting that controls whether the user is forcibly logged off or not when her smartcard is removed) generally live under HKLM\Software\Policies. User-specific settings live in HKCU\Software\Policies.

What about the things you could set with the SPE from NT 4.0? Most of these settings were moved to the GPOs, which means you modify them through the Group Policy snap-in. In Windows NT they were stored under HKLM\Software\Microsoft\Windows\CurrentVersion or HKLM\Software\Microsoft\Windows NT\CurrentVersion; in Windows 2000, they're stored in a new subkey called Policies under one of those two keys. As you'll see later in the chapter, settings in the GPO can still be applied to the Registry, just as they are with the SPE.

2.2.1.4 SYSTEM

The SYSTEM subkey contains a potpourri of critical data. If HKLM is the most important part of the Registry, SYSTEM is its most important subkey. It has four subkeys that merit further discussion:

The Disk subkey contains information stored by NT's Disk Administrator application: which drives have which drive letters, whether any drives are part of stripe or mirror sets, and so on. This information can later be used to help regenerate damaged disks or rebuild stripe and mirror sets if something goes boom. If you haven't run Disk Administrator on a machine, this subkey won't exist, and it doesn't exist on Windows 2000 machines.

Subkeys exist for each control set. A control set is nothing more than a group of driver settings, hardware profile settings, and Registry entries; one control set is loaded every time the system boots. Since you can change drivers, hardware profiles, and other control-set elements, the kernel creates one control set subkey under HKLM\SYSTEM for each control set it sees. At a minimum, there will be two sets: one that you last used to boot, and the last one that successfully booted. This "last known good" set can be a lifesaver when things go wrong, as you'll see in Chapter 3. When you change control-set settings, Windows 2000 creates a new control set. The sets are named with a sequence number; ControlSet001 is first, followed by ControlSet002, ControlSet003, etc.
The Select subkey remembers which control sets exist on the machine, which was the last known good set, and which was the last to cause a failed boot.
The MountedDevices subkey is new for Windows 2000. It's used by the Logical Disk Manager, a new system component that gives Windows 2000 the ability to mount, unmount, format, and repartition disks on the fly, without rebooting. There are two kinds of values here: the first kind (of the form \??\Volume{volID }) lists all the known volumes, while the second kind (of the form \DosDevices\driveLetter) ties known volumes to particular drive letters.
The Setup subkey is Windows 2000's way of detecting whether it's in the middle of installation. When you install Windows 2000, it goes through a multi-step installation process; once the first step completes, the machine actually boots into a "light" version of the OS so ntdetect can do its work and map the hardware. If this phase fails, the machine is in limbo: Windows 2000 isn't completely installed, but its boot loader is. The boot loader checks the value of HKLM\Setup to see whether Setup was running when the machine was last booted; if so, it restarts the setup process.

2.2.1.4.1 SYSTEM\CurrentControlSet

CurrentControlSet is almost, but not quite, a link to whatever control set was used to boot the machine. The kernel copies the current control set (as pointed to by the SYSTEM\Select key) to the CurrentControlSet and Clone keys early in the boot process. System services, control panels, and well-behaved applications use CurrentControlSet instead of using a particular ControlSetXXX key, since it may move or even be deleted without the application's knowledge. The structure of CurrentControlSet is thus identical to any of the ControlSetXXX keys; for convenience, I'll describe it since that's the actual subtree NT uses while running:

Control holds much of the system's configuration information. Among other things, subkeys of Control contain information about the time zone the machine's in (TimeZoneInformation), what directories contain Windows 2000 and its system files (Windows), and what the computer's network name is (ComputerName). These data are all static; the system loads them at startup. Though they can be changed, the changes don't normally take effect until the next time Windows 2000 boots. In Windows 2000, the Control subkey also contains a great deal of dynamically generated information. For example, the Control\PnP subkey lists the PCI cards and devices detected at the last boot.
Enum contains information about the hardware devices found in the system during the boot phase. It has two subkeys: HTREE and ROOT. HTREE contains subkeys for those devices that were actually found, while ROOT contains subkeys for all devices that have installed drivers.
In contrast to Control, Services holds configuration parameters for all of Windows 2000's services and kernel drivers. Some of these settings are new (such as the RemoteRegistry service and the smart-card server and client drivers), while others are left over from NT 4.0. When you add services, they typically add their own keys here as well.
Hardware Profiles holds the hardware profile settings that appear in HKCC. At a minimum, there are two entries under this key: Current holds the current profile, and 0001 holds the default profile. If you define multiple profiles, the profits get new sequence numbers: 0002 is the second profile you define, 0003 the third, and so on. Each profile's key in turn contains its own copy of the CurrentControlSet key that matches the profile.

2.2.2 Major Subkeys of HKCU

The user profiles stored under HKCU are actually made up of data from ten major subkeys. Since the values under these keys control most of the environment and desktop settings that NT lets you customize, it's worth examining each of these subkeys.

2.2.2.1 AppEvents

The AppEvents subkey stores the mappings between system events (new mail arrived, window maximized, Windows logout, and so on) and sounds. You set these mappings with the Sound control panel; in addition to the system events, applications can define their own events (Visual C++ defines "compilation done"). When a listed event occurs, NT can look in HKCU\AppEvents and play the appropriate sound.

2.2.2.2 Console

Console stores the console window properties you set with the Console control panel or the "Command Line" Properties dialog available from the console window itself. When you change the default command-line window's size, position, buffer size, or font, those changes are stored here.

2.2.2.3 Control Panel

Control Panel doesn't directly store anything; instead, it's a placeholder for the system's control panels. Each control panel that wants to store persistent settings on a per-user basis can create its own subkey under HKU\Control Panel and use it however it wants. Control panels that manage systemwide settings, such as the Network and System panels, store their settings in subkeys of HKLM.

2.2.2.4 Environment

Environment holds the user-defined environment variables set in the Environment Variables dialog (triggered by the button of the same name on the System control panel's Advanced tab). Systemwide environment variables are kept in HKLM\System\CurrentControlSet\Control\Session Manager\Environment.^[9] Interestingly, when you make changes to the user-environment variables, the changes don't take effect until you log off and back on, but changes to the system's environment variables take effect immediately (though applications that use environment settings may need to be restarted to pick up the changes).

^[9] Okay, you caught me; they're really kept in HKLM\System\ControlSetXXX.

2.2.2.5 Identities

If you're using Outlook Express or MSN Messenger, the Identities subkey contains subkeys for each mailbox or message recipient identity. This allows multiple users to share an Outlook Express installation, keeping each individual "personality" separate from the others.

2.2.2.6 Keyboard Layout

Keyboard Layout retains the user's preferred keyboard layout. If you're used to the standard U.S. English layout you may not know that, like the Mac, Windows 2000 supports international keyboards whose layouts are different from the standard QWERTY layout. For example, the standard French keyboard's upper row starts with AZERTY. Windows 2000 needs to know the physical layout of the keyboard so it can map keystrokes to the appropriate character codes, especially since you can switch between input locales on the fly.

2.2.2.7 Printers

The Printers key has two subkeys. Settings stores the user's default print settings, including the name of the default printer and whatever page-setup parameters the user has set. Connections contains one subkey for each installed printer to which the current user can print. If no printers have been defined, this key is either empty or missing, since Windows 2000 creates it the first time a printer's created. Once a printer's been defined, a new subkey named after the print server and printer (for example, ARMORY,HP5M Postscript) appears under Connections. The new subkey's values store the name of the printer driver DLL used with the printer and the name of the print server (if any) that shares the printer to other users.

2.2.2.8 Remote Access

This subkey holds settings used by the Dial-Up Networking system.

2.2.2.9 Software

Software, like Control Panel, is a placeholder for a set of subkeys. The exact list of subkeys varies, since any software vendor can create program-specific keys. Applications are supposed to use HKCU\Software for user-specific settings (such as the location of private mail folders) and keep their systemwide settings in HKLM\Software; however, many applications don't have any systemwide settings, so they keep everything under HKCU\Software.

2.2.2.10 SYSTEM

It might seem that HKCU and HKLM\SYSTEM would mix about as well as motor oil and Perrier. Normally, that's true; however, Windows 2000 allows users to set some per-user options that override settings that usually live in HKLM. For example, the spiffy new Windows 2000 Backup utility lets you specify which files not to back up; if you override the default settings for a particular user, HKCU\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup contains that user's list of files to be excluded. Likewise, other applications and components can store settings in HKCU\SYSTEM if they override corresponding settings somewhere in HKLM.

It turns out that this subkey exists only when an application (such as Windows 2000 Backup) creates it. A brand-new 2000 installation doesn't have this key.

2.2.2.11 Other

UNICODE Program Groups holds program group settings from previous versions of NT installed on the machine. This key is always present, but on machines that have never had a pre-4.0 version of NT, it is empty. On machines that have been upgraded from NT 3.x to NT 4.0, it contains information about the defined user and system Program Manager groups, but the key's main purpose under NT 4.0 is as a placeholder for backward compatibility.

The Volatile Environment key stores per-user environment settings that change between logon sessions. The only key NT 4.0 routinely creates here is LogonServer, which points to the computer that validated the user's logon.

On Windows NT systems that were upgraded from Windows 3.x, there is a Windows 3.1 Migration Status subkey under HKCU. This subkey, which is also present on NT machines upgraded from Windows 3.x to NT to Windows 2000, stores the contents of the original REG.INI file, as well as assorted settings from other INI files. NT can automatically map INI files to sections in the Registry, making it possible for 16-bit applications to automatically use the Registry without being rewritten. (For more information on building your own mappings, see Section 9.2 in Chapter 9.)

2.2.3 Major Subkeys of HKCC

HKCC was originally introduced in Windows 95, and it appeared in NT 4.0 strictly to allow Win95 applications that use HKCC to run under NT. Windows NT and 2000 both support the concept of multiple hardware profiles; a profile is just a small set of Registry keys that define the hardware available to the computer. The most often-cited example for which hardware profiles are useful is that of a laptop. Let's say you buy a fancy laptop and a docking station, then install Windows 2000 on it. You can use the laptop in three configurations:

At your office, plugged into the docking station. You can use your docking station's display adapter and Ethernet card, and you have access to DNS, DHCP, and WINS servers for your intranet.
On the road, with a PC Card modem to give you dial-up access to your intranet. In this mode, you need drivers for the modem and Dial-Up Networking, and you need different settings for all your network software. You also don't want the drivers for your docking station loaded.
In the field, where you have no net access (well, you could use a satellite phone, but at $6/minute let's just stick with the "no access" plan).

Each configuration can be stored as a unique hardware profile. When you boot Windows 2000, you can tell it which one to use, and Windows 2000 loads the appropriate drivers and settings. All the machine's hardware profiles are stored in the Hardware Profiles subkey of control sets under the HKLM\System tree. More importantly, system components and applications that are savvy enough to know about HKCC can query it to see what kind of hardware is currently installed.

HKCC contains two subkeys: Software and System\CurrentControlSet. These are sufficient to store the individual profile settings; as you learned earlier in the chapter, CurrentControlSet actually stores driver settings. In addition, HKCC stores the settings that are different from the default. If you use a profile that adds devices not present in the default profile, they are added in HKCC and merged with the default set.

2.2.4 What About the Other Root Keys?

At this point, you might be wondering why this chapter doesn't discuss the major subkeys of HKCR, HKPD, and HKU. The real reason is that none of these root keys has any particularly interesting subkeys under them! HKPD is opaque and can't be browsed. HKCR has many subkeys, each of which has the same format and similar contents, and it's only a link to portions of HKLM\Software\Classes anyway. Finally, HKU 's structure and contents are described earlier in this chapter in Section 2.2.2. The subkeys discussed in that section are the real meat of the Registry; for more details on individual subkeys not covered here, see Chapter 11.

One interesting difference in Windows 2000 is that class data is split between HKCR and HKCU\Classes, at least from the OS' point of view. Users and applications, though, see a single seamless set of class registrations because Windows 2000 merges HKCR and HKCU\Classes so that a query under HKCR actually queries both of them.