The HKEY_LOCAL_MACHINE Key

The HKEY_LOCAL_MACHINE Key

HKEY_LOCAL_MACHINE is one of the most important and most interesting root keys of the registry. It contains configuration data for local computer. Information stored in this registry key is used by applications and device drivers and by the operating system itself for obtaining information on the local computer's configuration. Moreover, the information doesn't depend on the user who's logged in to the system.

The HKEY_LOCAL_MACHINE root key contains five subkeys, briefly described in Table 7.1. The rest of this section describes the subkeys in greater detail.

Table 7.1: Subkeys Contained within the HKEY_LOCAL_MACHINE Root Key

Subkey	Contents
HARDWARE	This subkey contains a database describing all the hardware devices installed on the computer, the method of interaction between device drivers and hardware devices, and the data that connects kernel-mode device drivers with user-mode code. All the data contained within this subkey are volatile. The system re-creates these data each time it starts. The Description subkey describes all the hardware physically present on the computer. The hardware recognizer collects this information at system startup and the kernel stores this information under the HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION registry key. The DeviceMap subkey contains various data in formats defined by certain device driver classes. As device drivers are loading, they pass their information to the system so that it can associate specific hardware devices and their drivers.
HARDWARE	The ResourceMap subkey contains information on the system resources allocated to each device (including ports, DMA addresses, IRQs). Notice that all Windows NT-based operating systems, including Windows 2000, Windows XP and Windows Server 2003 provide a much more convenient way to view the contents of this subkey. To view (and possibly change) this data, it is recommended that you use various administrative tools. For example, if you're using Windows NT 4.0, you can view the information using the Windows NT Diagnostics utility (Winmsdp.exe). In Windows 2000/XP and Windows Server 2003, you can use the MMC console or Device Manager for the same purpose.
SAM	This subkey contains the directory services database, which stores information on user and group accounts and security subsystems (SAM stands for the Security Account Manager). By default, you can't view this key using registry editors even if you're logged in as an Administrator. The data contained within the HKLM\SAM registry key isn't documented, and user passwords are encrypted. Note that for Windows NT domains the SAM database also stores a domain directory services database. In native-mode Windows 2000 or Windows Server 2003 domains, the directory services database is stored in the Ntds.dit file on domain controllers. However, the SAM database remains important, since it stores local accounts (required to log on locally). If your computer that is running Windows XP or Windows Server 2003 does not participate in a domain, SAM database is the main storage of the user and group accounts information.
SECURITY	This database contains the local security policy, including user rights and permissions. The key is only used by the security subsystem. For example, it contains information that defines whether or not an individual user can reboot the computer, start or stop device drivers, backup/recover files, or access the computer through the network. Information contained within this key is also encrypted. The HKLM\SAM key is the link to the HKLM\SECURITY\SAM key.
SOFTWARE	This database contains information on the software products installed on the local computer, along with various configuration data.
SYSTEM	This database contains information on controlling the system startup, the loading order of device drivers and system services, and on operating system behavior.

Note 

You can read the information contained in any of these subkeys, but it only makes sense to edit the contents of the Software and System keys.

If the HKEY_CURRENT_USER registry key contains data similar to that contained under HKEY_LOCAL_MACHINE, then by default the HKEY_CURRENT_USER data takes priority.

Note 

If you read the previous chapter carefully, you'll recall that the Policy setting under HKEY_LOCAL_MACHINE is given priority over the individual settings specified for each user. This is only true if you logged in to the system as an Administrator and specified the default value for the power policy, as described in Chapter 5.

However, the settings under this key may also extend the data under HKEY_LOCAL_MACHINE rather than replace them. Furthermore, there are certain settings (for example, those that manage the device driver loading order) that have no meaning outside the HKEY_LOCAL_MACHINE root key.

The HKEY_LOCAL_MACHINE\HARDWARE Key

The HKEY_LOCAL_MACHINE\HARDWARE registry key contains hardware data recreated during each system startup. This data includes information about the devices on the motherboard and the data on the IRQs used by individual device drivers.

The HARDWARE key contains important data sets subdivided between the following three subkeys: DESCRIPTION, DEVICEMAP, and RESOURCEMAP.

All the information contained under HKEY_LOCAL_MACHINE\HARDWARE is volatile. This means that the settings are computed and recreated each time the system starts up, and are lost when you shut the system down. All drivers and applications use this subtree for obtaining information on system components and for storing the data directly under the DEVICEMAP subkey and indirectly under the RESOURCEMAP subkey (Fig. 7.1).

Figure 7.1: The HKEY_LOCAL_MACHINE\HARDWARE registry key

Note 

As was explained in Chapter 5, integrated support for Plug and Play and power management in Windows 2000, Windows XP, and Windows Server 2003 is only available on computers that have an Advanced Configuration and Power Interface (ACPI) BIOS. At boot time, the operating system loader checks whether such a BIOS is loaded. If so, ACPI is enabled in the operating system. If such a BIOS is not loaded, ACPI is disabled and the less reliable Advanced Power Management (APM) model is used instead. Microsoft supplies the ACPI driver as part of the operating system. On systems that have an ACPI BIOS, the HAL causes the ACPI driver to be loaded during system start-up at the base of the device tree, where it acts as the interface between the operating system and the BIOS. The ACPI driver is transparent to other drivers. If your system has ACPI BIOS, the HKEY_LOCAL_MACHINE\HARDWARE registry tree will contain the nested ACPI subkey (Fig. 7.1).

Don't try to edit the data under HKEY_LOCAL_MACHINE\HARDWARE directly. This information is usually stored in binary format and is difficult to understand if you can't interpret binary data.

Tip 

If you want to view this information in user-friendly format, select Programs | Administrative Tools | Computer Management from the Start menu and expand the MMC console tree (Windows 2000) or click Start | All Programs | Accessories | System Tools | System Information (Windows XP and Windows Server 2003) to open the System Information window (Fig. 7.2).

Figure 7.2: The System Information utility allows you to view hardware information in user-friendly format

The DESCRIPTION Subkey

The DESCRIPTION subkey under HKEY_LOCAL_MACHINE\HARDWARE displays information from the hardware database. For x86 computers, this information contains data on the devices detected by Ntdetect.com and Ntoskrnl.exe.

Ntdetect.com is the standard DOS-style program that uses BIOS calls for selecting hardware information and configuring hardware devices. This includes date and time information stored in the CMOS chip; bus types (for example, ISA, PCI, EISA) and identifiers of the devices on these buses; data on the number, type, and capacity of the hard drives installed in the system; and the number and types of parallel ports. Based on this information, the system creates internal data structures that Ntoskrnl.exe stores under HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION during system startup.

A specific feature of the Ntdetect.com version included with Windows 2000, Windows XP, and Windows Server 2003 is that PnP detection functions are delegated to PnP drivers. In contrast, the Windows NT 4.0 version of Ntdetect.com detects all installed hardware (due to limited PnP support in Windows NT 4.0).

Ntdetect.com detects the following hardware:

• Type of bus\adapter

• Keyboard

• SCSI adapters

• COM-ports

• Machine ID

• Video adapter

• Arithmetic coprocessor

• Mouse

• Floppy drives

• Parallel ports

Note 

Network adapters aren't detected at this phase. The system detects network adapters either during OS installation, or when you install a new network adapter. More detailed information on this topic will be provided in Chapters 8.

There are more subkeys, each of them corresponding to a certain bus controller type. These subkeys are located under HKEY_LOCAL_MACHINE\Hardware\Description\System\MultifunctionAdapter. Each of these keys describes a specific controller class (including hard disk controllers, display controllers, parallel port controllers, and SCSI controllers). The path to the subkey describes the component type. All physical devices are numbered, beginning from 0.

Each detected hardware component has Component Information and Configuration Data settings, which contain binary data on the version of a specific component and its configuration (Fig. 7.3). The Identifier setting contains the component name (if specified).

Figure 7.3: The HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\MultifunctionAdapter registry key

The DEVICEMAP Subkey

The HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP registry key contains a set of sub-keys equipped with one or more settings that specify the path to the drivers required by each device. Let's consider using this information for searching for device drivers. For example, how does the registry store information on the video drivers? Fig. 7.4 shows an example illustrating the contents of the VIDEO subkey under the DEVICEMAP key (the information you'll see when you open the registry key will differ from what's shown in this figure). However, the information will show you what you'll see in general.

The HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\VIDEO registry key contains settings that are actually links to currently active devices. These registry items use an ordinal-naming scheme (for example, in Fig. 7.4 it's \Device\VideoN, where N is an ordinal number (0, 1, 2…)). The values of each of these registry settings are REG_SZ strings that reference particular device drivers.

Figure 7.4: The HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\VIDEO registry key

Note 

Notice that these strings have a specific data format. For example, the Device\Video0 setting represented in Fig. 7.4 is set to \Registry\Machine\System\CurrentControlSet\Control\Video\{56652C39-3E1C-4A83-AD68-1CF58F0EDEE9}\0000 value. This format is different from the one that's normally used (for example, HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER). What does this mean?

All Windows NT-based operating systems, including Windows 2000, Windows XP, and Windows Server 2003, are object-oriented, which means that they manipulate several object types, including devices, ports, events, directories, and symbolic links. Registry keys are objects of special types. The registry root key is the object of the Key type named REGISTRY. In the DDK (Device Driver Kit) documentation, the names of all the registry keys begin with the \REGISTRY string (for example, \REGISTRY\Machine\CurrentControlSet\Services). Thus, the HKEY_LOCAL_MACHINE handle is the key named \REGISTRY\Machine, and the HKEY_USERS handle is the key named \REGISTRY\User.

Now let's expand the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\{56652C39-3E1C-4A83-AD68-1CF58F0EDEE9}\0000 registry key (Fig. 7.5).

Figure 7.5: The contents of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\{56652C39-3E1C-4A83-AD68-1CF58F0EDEE9}\0000 registry key

This key contains quite a lot of entries, mainly in binary format, among which is the Device Description value (data type REG_SZ) that contains the device description (NVIDIA RIVA TNT, in our example). Besides, it also possesses another value, InstalledDisplayDrivers, which references the driver for this device (nv4_disp in our example). The nested Video key contains the Service value entry referencing the nv service (Fig. 7.6). Information on this service can be found in the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services registry key (Fig. 7.7). It must exist for the device to function properly, and you'll certainly find it.

Figure 7.6: The contents of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\{56652C39-3E1C-4A83-AD68-1CF58F0EDEE9}\Video registry key

Figure 7.7: The contents of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\nv registry key

Tip 

Use Regedit.exe searching capabilities to find the key, since in our case this is the easiest way to locate the required key.

The key that you are locating contains standard settings that specify the start mode for the driver: Start, Tag, Type, ErrorControl, and Group. Depending on the driver type, its key may contain several other settings, such as the ImagePath setting that specifies an actual path to the directory where the driver resides (system32\DRIVERS\nv4_mini.sys, in our example).

Note 

Notice how the image path has been specified. The loading order for the driver is specified by the Start setting (as we saw in the previous chapter). Sometimes the system doesn't assign drive mappings at the time the driver's loaded. Because of this, an error may result if you specify, for example, "C:\WINNT\System32\DRIVERS\<YourDriver>" as a value for ImagePath.

The HKEY_LOCAL_MACHINE\SYSTEM\ControlSetnnn\Services\<Driver> key may contain an optional REG_SZ setting named DisplayName. The value assigned to this parameter is a text string displayed by administrative utilities. If the DisplayName setting is omitted, then the actual name of the service or driver will be displayed in the list.

In addition to the settings listed above, the video driver key under HKEY_LOCAL_MACHINE\SYSTEM\ControlSetnnn\Services contains several subkeys. One of the most important subkeys within this key is DeviceN-in our example, this is the Device0 subkey (Fig. 7.8).

Figure 7.8: An example of the contents of the DeviceN nested key for the device driver subkey under HKEY_LOCAL_MACHINE\SYSTEM\ControlSetnnn\Services

Depending on the video driver implementation, this key may contain a variety of parameters, including the VgaCompatible standard setting, which is set to FALSE for most modern drivers. If the parameter is set to FALSE, the driver is based on the MS VGA miniport driver.

The following REG_BINARY settings under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\{56652C39-3E1C-4A83-AD68-1CF58F0EDEE9}\0000:

   HardwareInformation.AdapterString,   HardwareInformation.BiosString,   HardwareInformation.ChipType,   HardwareInformation.Crc32,   HardwareInformation.DacType   HardwareInformation.MemorySize

contain hardware information displayed by administrative utilities. Notice that similar settings are also present in Windows NT/2000 registries, but under different locations.

When Windows GUI starts, the system reads the video settings contained under the following registry key (Fig. 7.9):

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\   Hardware Profiles\Current\System\CurrentControlSet\Control\VIDEO\   {56652C39-3E1C-4A83-AD68-1CF58F0EDEE9}\0000 

Figure 7.9: Registry settings that specify the video mode

After reading these settings, the system checks whether the display driver supporting the specified mode is present. As soon as the appropriate driver has been found, the startup procedure continues. What happens, though, if the system can't find an appropriate driver? The answer's simple: the system will use standard VGA mode (16 colors).

Thus, we have considered the usage of the HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP information for searching for specific device driver data. We've used the video adapter as an example, but the system uses a similar algorithm for locating the appropriate drivers for any other device. To summarize, let's note that the HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP data describes either an actual port name or the path to the appropriate subkey under HKEY_LOCAL_MACHINE\System\ControlSetnnn\Services. This, in turn, contains the necessary information on the device driver. Sometimes, system administrators may need this information for troubleshooting purposes. It should be noted again that administrative utilities, such as Device Manager, display the same information presented in user-friendly format rather than raw binary data.

The RESOURCEMAP Subkey

The RESOURCEMAP subkey under HKEY_LOCAL_MACHINE\HARDWARE maps device drivers and hardware resources allocated to these drivers. Each setting stored within the RESOURCEMAP key contains the data reported by the device driver concerning memory addresses, IRQs, and DMA channels requested by respective drivers. All the data contained within this key is volatile. Windows NT/2000/XP and Windows Server 2003 recreate the key during every system startup.

Because Windows 2000/XP and Windows Server 2003 implement full-featured Plug and Play support and include a new kernel-mode component (Plug and Play Manager), the contents of the HKEY_LOCAL_MACHINE\HARDWARE\RESOURCEMAP registry key are different for Windows 2000/XP/Windows Server 2003 from what they are for Windows NT 4.0. In the Windows NT 4.0 registry, the RESOURCEMAP key contains multiple <DeviceClass> subkeys, which are used to store information on specific device driver classes. Each of these keys contains one or more <DriverName> subkeys that store information related to individual drivers.

The RESOURCEMAP key in Windows 2000\Windows XP\Windows Server 2003 registries looks somewhat different (Fig. 7.10). The kernel-mode Plug and Play Manager now controls all the hardware devices. Because of this, the data concerning system resources is stored under the following registry key: HKEY_LOCAL_MACHINE\HARDWARE\RESOURCEMAP\PnP Manager\PnpManager.

Figure 7.10: The RESOURCEMAP key in Windows XP/Windows Server 2003

The HKEY_LOCAL_MACHINE\SAM Key

For computers that are not joined to a domain, the HKEY_LOCAL_MACHINE\SAM registry key contains information on local user and group accounts stored in the directory database (which was formerly known as the SAM database). For Windows 2000 Server and Windows Server 2003 computers joined to a domain, this key also contains security data for domain users and groups.

This key references the HKEY_LOCAL_MACHINE\Security\SAM key, and any modification introduced into one of these keys is immediately introduced into another one.

Note 

Starting with Windows 2000, domain controllers both in Windows 2000 and Windows Server 2003 domains store security data in the Active Directory database file (Ntds.dit). However, SAM database is still preserved for storing local security information on servers that are not joined to a domain, as well as for backward compatibility with the existing Windows NT 4.0 domains. Besides this, it is used for restoring Active Directory information when the user selects the Directory Services Restore Mode (Windows domain controllers only option from the Windows Advanced Startup Options menu during system boot.

Default security settings both in Windows 2000 Server and in Windows Server 2003 prevent users (even those with administrative permissions) from viewing the contents of this registry key. More detailed information on this topic will be provided in Chapter 9.

The HKEY_LOCAL_MACHINE\SECURITY Key

The HKEY_LOCAL_MACHINE\SECURITY registry key contains information about the security subsystem on the local computer, including user rights and permissions, password policies, and local group membership. All of this information is specified using administrative utilities such as User Manager (Windows NT 4.0 Workstation), User Manager for Domains (Windows NT 4.0 Server), User Management MMC snap-in (Windows 2000 Professional and Windows XP) and Active Directory Users and Computers (Windows 2000 and Windows Server 2003 domain controllers).

The HKEY_LOCAL_MACHINE\SECURITY\SAM key references the HKEY_LOCAL_MACHINE\SAM key; because of this, any modification introduced into one of these keys will immediately appear within another one.

The HKEY_LOCAL_MACHINE\SOFTWARE Key

The HKEY_LOCAL_MACHINE\SOFTWARE registry key contains configuration data concerning the software installed on the local computer. Settings that reside under this key contain settings for the software installed on the local PC and are in force for any user who's logged on to the local system.

The HKEY_LOCAL_MACHINE\SOFTWARE\Classes key contains filename extension association data. It also stores registry data associated to COM objects. The data stored under the Classes key are also displayed under HKEY_CLASSES_ROOT. Fig. 7.11 shows the typical contents of the HKEY_LOCAL_MACHINE\Software registry key.

Figure 7.11: Typical contents of the HKEY_LOCAL_MACHINE\SOFTWARE key

The HKEY_LOCAL_MACHINE\SOFTWARE subtree contains several nested keys, the most important being the Classes, Program Groups, and Secure subkeys. Later in this chapter, we'll discuss several <Description> subkeys that may appear in the registry.

The Classes Subkey

The parameters contained under this key are the same as the parameters stored under HKEY_CLASSES_ROOT. Detailed information on the contents of this key is provided in the "OLE Programmer's Reference" document included with the Windows Platform Software Development Kit. The HKEY_LOCAL_MACHINE\SOFTWARE\Classes key contains subkeys of the following types:

• Subkeys of the <Filename-extension> type associate applications installed on local computers with file types (identified by filename extensions). These subkeys contain data that you can add using the File Types tab of the Folder Options window, as well as information added by the Setup programs that install Windows applications.

• <Class-definition> subkeys. These subkeys contain information associated with COM objects. The data contained within these keys specify the shell and OLE (COM) properties for specific objects. If the application supports DDE (Dynamic Data Exchange), the Shell subkey may, in turn, contain other subkeys such as Open and Print. The subkeys define DDE commands for opening and printing files. Notice that the information contained under these keys is very similar to that which is stored in the registry database of previous Windows versions, such as Windows 3.1x.

Note 

The COM object information contained in the registry must be created by an application supporting COM. Direct registry editing can't be considered the easiest method of editing the information. If you need to perform this task in Windows NT 4.0, select the Options command from the View menu in Windows NT Explorer, then go to the File Types tab of the Options dialog. If you need to perform the same task in Windows 2000, Windows XP, or one of the Windows Server 2003 products, start the Folder Options applet from the Control Panel, or select the Folder Options command from the Tools menu in Windows Explorer; then go to the File Types tab in the Folder Options window.

The Description Subkeys

The HKEY_LOCAL_MACHINE\Software\Description keys contain names and version numbers of the software installed on the local computer. (Configuration settings specified for individual users are stored under HKEY_CURRENT_USER.)

During installation, applications register this information in the following form:

   HKEY_LOCAL_MACHINE\Software\Description\CompanyName\ProductName\Version.

Note 

Version information for each application must be added to the registry by the appropriate application. Don't edit values under these keys except when the application vendor instructs you to do so.

An example illustrating how the registration information of an application (AvantGo in our case) is stored under the HKEY_LOCAL_MACHINE\SOFTWARE registry key is presented in Fig. 7.12.

Figure 7.12: An example of application registration information under HKEY_LOCAL_MACHINE\Software registry key

The Microsoft Subkey

The HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft subkey contains configuration settings for Microsoft software products installed on the local computer.

One of the most important subkeys under HKLM\SOFTWARE\Microsoft is the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion key. This key contains information on the software that supports Windows built-in services and the type and version number of the current OS installation (for example, the data specify whether the system has a multiprocessor kernel). Obviously, a single-processor kernel will work on a multi-processor computer, but it won't provide any advantages over the single-processor configuration. To identify the kernel type, view the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion (Fig. 7.13).

Figure 7.13: The HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion registry key

Note 

When speaking about the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion registry key, it is simply impossible not to mention one of the most appreciated performance enhancements introduced with Windows XP and Windows Server 2003. These newer operating systems provide built-in user mode heap-leak detection. The problem is that poorly written or miscoded applications can "leak" heap memory. In versions released earlier than Windows XP, special tools were needed to help identify the cause of the memory leak when this situation arose. To enable leak detection, set the following registry key:

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\   Image File Execution Options\<ImageName>]   "ShutdownFlags"="3"

The Program Groups Subkey

The Program Groups subkey, residing under the HKEY_LOCAL_MACHINE\Software registry key, has undergone some changes in comparison to previous versions of Windows NT (Windows NT 3.51 and earlier). In Windows NT 4.0, this key was redefined. In earlier Windows NT versions, the key contained a list of program groups used by all users of the local computer. In Windows NT 4.0 and its successors, this key is only used to specify whether or not all the program groups that existed in the previous operating system (for upgraded systems) were converted to a new format.

The Program Groups key contains a single entry named ConvertedToLinks, which determines whether the program groups have been converted. If the ConvertedToLinks value is set to 1, the conversion has been completed successfully.

If you install a fresh copy of the operating system rather than upgrade an earlier version to Windows XP or Windows Server 2003, the Program Groups subkey won't contain any subkeys. If you've performed an upgrade, the Program Groups key will contain subkeys containing binary data defining general program groups.

The Secure Subkey

Applications can use the Secure subkey for storing configuration settings that can only be changed by the system administrator.

The Windows 3.1 Migration Status Subkey

The Windows 3.1 Migration Status subkey contains data only if the current operating system was installed as an upgrade from Windows 3.1. The parameters contained in this key specify if all INI files and the registry database (Reg.dat) were successfully converted to the Windows NT 4.0\Windows 2000 registry format.

If you delete this key, Windows will make another attempt to convert these files after rebooting.

Windows 3.1 Migration Status also exists under HKEY_CURRENT_USER. It specifies the conversion status of the program groups files (GRP files) to the Windows Explorer program group format.

The HKEY_LOCAL_MACHINE\System Key

All the data related to the startup process, which the system needs to read rather than calculate, are stored in the System hive. The System.alt file (existing in Windows 2000 and earlier) also contains complete copies of these data. The data stored under HKEY_LOCAL_MACHINE\System are organized into Control Sets, each containing a complete set of parameters for device drivers and system services. Now and then, the system administrator may need to edit the items stored under the CurrentControlSet subkey.

Chapter 6 contains detailed information on the contents of the CurrentControlSet subkey.

The ControlSetnnn, Select, and CurrentControlSet Subkeys

The registry, in particular the System hive, has the most important role at system startup. To guarantee that the system will start, Windows NT-based operating systems save the backup copy, allowing you to discard any configuration modifications that have led to unexpected results. In this section, we'll discuss the mechanism used for this purpose.

All data necessary to control the startup process are organized in subkeys called Control sets. Each control set contains the following four subkeys:

• The Control subkey that contains configuration settings used for system management, including the network name of the local computer and subsystems that should start.

• The Enum subkey contains hardware data, including data on the hardware devices and drivers to be loaded.

• The Hardware Profiles subkey contains hardware settings and driver configurations related to the individual hardware profile. You can create individual hardware profiles for each control set. The Hardware Profiles subkey will contain any data if only the data are different from the standard settings for device drivers and system services. The current hardware profile stored under CurrentControlSet is also stored under the HKEY_CURRENT_CONFIG root key.

• The Services subkey contains a list of drivers, file systems, and service programs that run in user mode, together with virtual hardware keys. The data contained in this key define the drivers to be loaded and specify their loading order. The data also define the methods used by the services to call each other.

Multiple control sets are stored as subkeys under the HKEY_LOCAL_MACHINE\System registry keys under the names from ControlSet00l to ControlSet003. There can be as many as four control sets, but normally there are only two. This mechanism is similar to the one used to create the Config.sys backup copies for MS-DOS computers. Normally, there's one copy of Config.sys used to start the system, and the backup copy. In our case, however, the whole job of creating and maintaining the backup copies is performed automatically by the system.

The Select subkey, shown in Fig. 7.14, contains four parameters, which describe the control set usage:

• The Default setting identifies the number of the control set (for example, 001=ControlSet001) that the system should use next time it starts up. This may happen when a system error prevents the system from booting or when you manually select the LastKnownGood option.

• The Current setting specifies the ordinal number of the control set that's actually been used to start the computer.

• The LastKnownGood setting specifies the ordinal number of the control set that was used the last time you successfully started up the system.

• The Failed setting specifies the control set that was replaced by the LastKnownGood control set (if it was used to start up the system). You can also examine this control set to identify the source of the problem, which you have to do in order to replace the current control set with the last known good one.

Figure 7.14: The contents of the HKEY_LOCAL_MACHINE\SYSTEM\Select registry key

The CurrentControlSet key is actually a symbolic link to the control set specified by the Current setting under HKEY_LOCAL_MACHINE\SYSTEM\Select. This is necessary so that constant paths can be used to refer to subkeys in the currently used control set, even though its name may change.

Any time you start the system, the control set used to start up the system is stored under HKEY_LOCAL_MACHINE\System\Clone. If the system started successfully, this control set is considered "good", and the system discards the existing LastKnownGood control set. Actually, the system replaces the existing LastKnownGood control set with a copy of the Clone key. The system administrator can change this requirement at the startup process. Normally, startup is considered successful if no severe errors occurred and at least one user was able to log on to the system.

The LastKnownGood configuration is used when you select the LastKnownGood option during startup, or if the startup process fails (in this case, the control set won't be considered "good"). If this happens, the system creates a new control set by copying the LastKnownGood control set. The values under HKEY_LOCAL_MACHINE\System\Select will change as follows:

• The control set identified as Default will became the Failed control set.

• The control set that was identified as LastKnownGood will become the Default control set.

User profile data are stored under other registry keys, and these modifications won't be reflected in user profiles.

Tip 

If you need to identify the control set used to start up your system, view the Select subkey.

Using administrative utilities and Control Panel applets is the easiest method of modifying the data stored under the keys previously discussed.

It's the CurrentControlSet subkey that you need to edit when modifying the configuration settings using one of the registry editors.

Control Subkeys for Controls Sets

Each control set contains a Control subkey. This subkey stores the startup parameters, including information on the subsystems to be loaded, environment variables, and the size and location of the paging file. The most important subkeys located under the Control key present in the control set are listed in Table 7.2.

Table 7.2: Typical subkeys of the Control Key for All Control Sets

Subkey	Description
BackupRestore	This key contains nested keys that specify parameters for the Ntbackup program, including subkeys such as FilesNotToBackup and KeysNotToRestore (Fig. 7.15), which contain exclusion lists for files and registry keys not to be involved into backup or restore processes. The contents of the BackupRestore subkey can be used for customizing the built-in Microsoft Backup utility. Also notice the AsrKeysNotToRestore nested key, which is new in Windows XP and Windows Server 2003. This key relates to the Automated System Recovery process, which in newer releases has replaced the Emergency Repair Disk functionality included with Windows NT and Windows 2000. By default, it contains a single value entry named Plug ' Play (data type REG_MULTI_SZ, value CurrentControlSet\Control\CriticalDeviceDatabase\). This information will not be restored during the ASR process, which is not surprising, since such information must be re-created by the Setup program when it inspects the hardware configuration of your system.
BootVerificationProgram	This value can be used to specify a non-standard mechanism of declaring the system startup as successful ("good"). If an additional verification mechanism hasn't been specified, this subkey won't contain any settings.
ComputerName	Default computer names and active computer names are stored under ComputerName and ActiveComputerName subkeys. To set the computer name, use the Network option in the Control Panel (Windows NT 4.0), the Network Identification tab in the System Properties window (Windows 2000) or the Computer Name tab of the System Properties window (Windows XP and Windows Server 2003).
CrashControl	This key contains value entries that manage system behavior in case of a system crash, including options for creating a memory dump file. Notice the MinidumpDir string value, which is new to Windows XP and Windows Server 2003. As its name implies, this setting specifies the path to the directory where the small dumps, mainly used by the Error Reporting service, are stored. You can specify these settings in the Startup and Recovery window.
GroupOrderList	Specifies the order in which the system should load the services for all groups that have one. This option is used in combination with the Tags option. The ServiceGroupOrder setting specifies the loading order for the groups.
ServiceGroupOrder	Specifies the order in which to load various groups of services. The services loading order within a group is defined using the Tags and GroupOrderList settings.
HiveList	This setting specifies the location of the registry hive files (the contents of this key are shown in Fig. 7.16). The value is maintained by the system because the settings under this key show the exact location of the registry hive files (if these files can't be loaded, the startup process will fail). Pay attention to the format used to represent the names of these settings (Fig. 7.16). Note that they are represented as follows: \REGISTRY\MACHINE\<hivename>, where the <hivename> is the name of the appropriate registry hive. Also note the following scheme: \Device\HarddiskVolumeN\%SystemRoot%\System32\Config\<hive>, which is adopted because when an appropriate registry file needs to be loaded, the system has not yet created drive mappings for logical disks.
KeyboardLayout	DLL for the keyboard layout, the default language used as a default, plus a subkey named DosKeybCodes, which lists all other available keyboard layouts.
LSA	The authentication packages for the Local Security Authority (LSA). This value is maintained by the system. If you make an error editing this value, it may prevent everyone from logging in to the local system.
NetworkProvider	This key can contain subkeys that specify network providers and the order in which to load them. You can manage the settings for network providers using the Network option in the Control Panel (Windows NT 4.0), the Network and Dial-up Connections option (Windows 2000) or Network Connections option (Windows XP and Windows Server 2003).
NLS	This subkey contains information on national language support (NLS). You can manage the national language support using the following Control Panel applets: Regional Settings (Windows NT 4.0), Regional Options (Windows 2000) or Regional and Language Options (Windows XP and Windows Server 2003).
Print	This subkey contains information on the currently installed printers and printing environment. It has the following important subkeys: Environments-this subkey contains other subkeys that define drivers and print processors for various system environments. Monitors-this subkey contains other subkeys that store data for specific network printing monitors. Printers-this subkey contains other subkeys that describe the settings for each installed printer. Providers-this key can contain subkeys describing print services' DLLs. To modify the printer settings, click the Start button, then select Settings | Printers.
PriorityControl	This subkey specifies the priority separation in Win32. You should only set this value using the System option in Control Panel.
ProductOptions	This subkey defines the software product type (Windows NT, for example). These values are maintained by the system. Notice one especially interesting fact: the ProductType value in Windows 2000 registry is set to "WinNT".
SessionManager	This subkey specifies global variables used by Session Manager. This key can, in turn, contain the following subkeys: DOS Devices-the subkey that identifies various DOS devices such as AUX, MAILSLOT, NUL, PIPE, PRN, and UNC. Environment-this key identifies environment variables such as ComSpec, Path, Os2LibPath, and WinDir. These variables are set using the System option in Control Panel (this is the same for both Windows NT 4.0 and Windows 2000 and its successors). FileRenameOperations-this key is used during the startup process. It allows you to rename certain files in order to replace them. These values should be maintained only by the operating system. KnownDLLs-this key defines the directories and filenames for Session Manager DLLs. Again, all these values are maintained by the operating system. MemoryManagement-this key defines the paging options. Normally, you specify the paging file parameters using the System applet in the Control Panel. Notice that in Windows NT/2000 this key contains the RegistrySizeLimit setting mentioned in Chapter 1. Also notice that in Windows XP and Windows Server 2003 this setting has become obsolete. SubSystems-this key defines information intended for Windows NT/2000, Windows XP, and Windows Server 2003 subsystems. The values under this key are maintained by the system.
Setup	This key specifies hardware setup options. Once again, all the values under this key are maintained by the operating system. If you need to modify these settings, the easiest way is to start the Windows Setup program.
TimeZoneInformation	This key contains the values that define time zone information. Normally, you set these values using the Date/Time option in the Control Panel.
VirtualDeviceDrivers	This subkey contains virtual device drivers. These values must be maintained by the system.
Windows	This subkey specifies the paths to the Windows directory and system directory.
WOW	The settings stored under this key define options for 16-bit Windows applications. Once again, these settings should be maintained by the system.

Figure 7.15: The contents of the BackupRestore nested key

Figure 7.16: The hivelist subkey

The Enum Subkey for All Control Sets

The Enum subkey contains configuration data for all hardware devices, independent of the drivers these devices use.

This subkey was first introduced in Windows NT 4.0. It was added to enable Windows NT to access devices and their drivers and manage them using methods similar to those used in Windows 95. (Notice that these methods are similar, but not the same, because Windows NT architecture is different from that of Windows 95.)

These changes were intended to lay the groundwork for providing support for new Plug and Play devices in future versions of Windows NT. As we saw in Chapter 5, full-featured PnP support was first implemented in Windows 2000, and further enhanced in Windows XP and Windows Server 2003.

Note 

Don't use registry editors to modify this key. If you make an error, neither Windows NT/2000 nor Windows XP/Windows Server 2003 will be able to detect hardware devices.

Normally, the Enum key contains configuration data for hardware devices. The subkeys under the Enum key form a hierarchical structure known as the hardware device tree. The hardware tree starts at the tree root and ends at the lowest branch containing configuration data for a specific instance of the device (for example, the keyboard on the local computer).

The Enum key itself can be considered to be a container that isn't associated with any value. This key contains at least two subkeys: the Htree subkey, which represents the hardware tree; and one or more enumerators, which are used by Windows to get information about specific devices.

The Htree\Root\0 key is a reserved registry space representing the root of the hardware tree (this is the same for Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003). Since Windows 2000 and newer releases implement full-featured Plug and Play support, the contents of the Enum key have become more complicated than those found in Windows NT 4.0. The screenshot shown in Fig. 7.17 shows the Enum key structure for Windows Server 2003.

Figure 7.17: The HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum key structure

The remaining subkeys directly under the Enum key represent enumerators and contain subkeys for devices on the same enumerator. According to Plug and Play requirements, each enumerator has its respective device bus (for example, PCI or ISAPNP). The default enumerator (Root) is used for non-PnP (legacy) devices.

Each subkey of the enumerator contains multiple subkeys that represent various device types and models. The subkeys representing device types, in turn, contain their own subkeys that identify specific instances of the devices of this type. The name of each device type subkey identifies the device as a legacy device or as a Plug and Play device.

For most non-Plug and Play devices, Windows NT-based OS creates a device-type ID in the LEGACY_<DriverName> format. This subkey contains data for all the devices managed by this driver.

The subkeys below the device type keys are keys representing specific device instances. They contain the setting, which specifies device configuration.

The settings and subkeys directly below the device instance keys may be different, and vary depending on the devices and their drivers.

The Services Subkey for All Control Sets

Each control set contains a Services subkey that lists the device drivers, file system drivers, and Win32 service drivers. All the drivers listed under this key may be loaded by the operating system boot loader (Ntldr), I/O Manager, or Service Control Manager.

As I already mentioned earlier in this chapter while discussing the HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP registry key, all the subkeys under this key contain the settings that reference the entries under the Services key within the control set. For example, in Windows NT/2000, the following entry may be present in the DeviceMap\PointerPort subkey for the parallel port mouse:

   \Device\PointerPort0:   \REGISTRY\Machine\System\ControlSet001\Services\Sermouse

The Services key must contain the key corresponding to this link, which is named Sermouse. This subkey identifies the mouse driver settings. This mechanism is called device mapping, which explains why the registry key is called DEVICEMAP.

Note 

In Windows XP and Windows Server 2003, to facilitate device installation, devices are set up and configured using device setup class grouping. The device setup class defines the class installer and class co-installer components that are involved in installing the device.

Therefore, the following entry for the parallel port mouse under HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\PointerClass will result (Fig. 7.18). Notice that the key name is PointerClass and not PointerPort, as it was in Windows NT/2000:

Figure 7.18: An example of the contents of the HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\PointerClass registry key in Windows XP

   \Device\PointerClass0:   \REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\Mouclass

Like in Windows NT/2000, the Services key contains the key corresponding to this link, which is named Mouclass. This subkey identifies the mouse driver settings (Fig. 7.19). At the beginning of the chapter, we discussed this mechanism in the example on video drivers.

Figure 7.19: The Services key contains the key corresponding to the link provided under DEVICEMAP registry key

Microsoft defines setup classes for most devices. IHVs and OEMs can define new device setup classes, but only if none of the existing classes apply. For example, a camera vendor doesn't need to define a new setup class because cameras fall under the Image setup class. Similarly, uninterruptible power supply (UPS) devices fall under the Battery class.

The class installer defines the class of the component to be installed by the ClassGuid value. There is a GUID associated with each device setup class. The ClassGuid value is the Globally Unique Identifier (GUID) for the class. You can generate GUID values using the Uuidgen.exe utility. More detailed information about this utility is provided in Platform SDK supplementary documents.

The device setup class GUID defines the … \CurrentControlSet\Control\Class\ClassGUID registry key under which to create a new subkey for any particular device of a standard setup class.

Each subkey under the Services key may contain several optional settings. For example, the content of the Alerter key specifies the Alerter service parameters.

Settings such as ErrorControl, Group, DependOnGroup, DependOnService, ImagePath, ObjectName, Start, Tag, and Type manage service behavior.

The loading order for services and drivers is specified by the \Control\ServiceGroupOrder key under the control set key.

The Hardware Profiles Key for All Control Sets

The Hardware Profiles subkey is present in any control set. These subkeys contain configuration data for all hardware profiles created in Windows NT/2000, Windows XP, or Windows Server 2003. This key was first introduced in Windows NT 4.0.

As you already know, the hardware profile is a set of modifications introduced to facilitate standard device and service configuration (including Win32 services and drivers) loaded at system startup.

Windows NT-based operating system creates a default hardware profile based on the original configuration detected during OS installation. You can create multiple hardware profiles and select existing profiles at boot time.

Fig. 7.20 shows a typical structure of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles registry key.

Figure 7.20: The contents of a typical HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles key

Each subkey under the Hardware Profiles key contains configuration data for its respective hardware profile. If the system has more than one hardware profile, it identifies the hardware profile as current when you select it at boot time. The HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles\Current registry key represents a symbolic link to one of the keys named 0000, 0001, …

The HKEY_CURRENT_CONFIG tree is an alias that references the Hardware Profiles\Current key under the CurrentControlSet. The contents of the Current key also appear under the HKEY_CURRENT_CONFIG tree.

Tip 

To define which of the 0000, 0001, …, 000n keys under the Hardware Profiles keys is selected as the current one, view the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\IDConfigDB key. This key contains the CurrentConfig setting (Fig. 7.21), whose value specifies the number corresponding to the key that contains the current hardware profile.

Figure 7.21: The contents of the IDConfigDB subkey

The settings contained within each hardware profile subkey represent individual modifications of the standard configuration of the system services and device drivers. These modifications correspond to the goals of each hardware profile. Notice that these keys only store data different from the standard configuration, which is defined by the data stored under the Software and System subkeys under HKEY_LOCAL_MACHINE. Consequently, the hardware profile structure is modeled based on the structure of the HKEY_LOCAL_MACHINE registry key. Strictly speaking, it can be considered to be a limited, or compressed, version of this key.

If the hardware profile contains a changed version of a value entry under the Software or System keys of HKEY_LOCAL_MACHINE, then the original value isn't changed. Rather, the changed version of this value is stored within a similar key of the Hardware Profiles\<Number> subtree.

For example, let's look at a situation when you create a new hardware profile that excludes the Iomega Parallel Port Legacy Filter Driver (ppa3). The HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\Root\LEGACY_PPA3 key won't be changed in Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003. On the contrary, this modification will be stored under the following key:

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Hardware Profiles   \<Number>\System\CurrentControlSet\Enum\Root\LEGACY_PPA3.

The Setup Subkey

The Setup subkey under the HKEY_LOCAL_MACHINE\System tree is intended for internal use by the Setup program. You need not (and should not) change the value entries under this key, because they are to be maintained by the operating system.

The Disk Subkey

The HKEY_LOCAL_MACHINE\SYSTEM\Disk subkey has undergone significant changes since its appearance in Windows NT 4.0. In the Windows NT 4.0 registry, this key contained all the information needed to manage the volumes. This key is created by the Disk Administrator built-in Windows NT utility and contains the Information setting (data type is REG_BINARY). This setting contains all configuration information, including the data on the hard disk partitions that were recognized by Windows, drive mappings, and the data concerning fault-tolerant disk configurations (mirror sets, stripe sets with or without parity), if you've created the fault-tolerant disk configurations. Detailed information concerning fault-tolerant disk configurations is provided in the documentation supplied with the Windows NT 4.0 Workstation Resource Kit software.

The HKEY_LOCAL_MACHINE\System\Disk key is created in the Windows NT 4.0 registry when you start the Disk Administrator utility for the first time. This utility creates both the key and the Information binary setting, which stores all the data on the hard disks present in the system. As you create or delete hard disk partitions using the Disk Administrator utility, or configure fault-tolerant volumes, the program stores all configuration changes in the Information setting.

If you explicitly establish drive mapping for the CD-ROM drive (for example, you need to map this drive as "H:"), the Disk key will contain another setting named \device\CdRom0. This string setting will have a value that corresponds to the drive mapping that you've specified. Besides the Disk Administrator utility, there are other drivers and subsystems that access the Disk key information. For example, this information is available to the fault-tolerant file system driver (Ftdisk.sys) and to the Win32 subsystem. The Ftdisk.sys driver identifies whether or not there are fault tolerant disk configurations in the system, such as mirror or stripe sets. The driver does this by reading the Information setting. The Win32 subsystem needs the Information setting data for establishing drive mappings.

Note 

The Information setting is a variable-length setting, because the number of logical disks and fault tolerant volumes in each individual Windows NT 4.0 system are also variable.

With the release of Windows 2000, the disk management subsystem has undergone significant changes (for example, a new type of volume was introduced-dynamic volume). The HKEY_LOCAL_MACHINE\SYSTEM\Disk\Information setting is present in the registry (in order to provide backward compatibility), but it no longer stores information on fault-tolerant volumes.

Windows 2000, Windows XP, and Windows Server 2003 store the information on fault-tolerant volumes directly on the hard disk. There's a noticeable difference, though. The Ftdisk.sys driver in Windows 2000/XP and Windows Server 2003 manages all disk partitions, including the fault-tolerant volumes and all other partitions that exist on the hard disks. So, even if you don't configure the fault-tolerant volumes on your computer running Windows 2000, Windows XP, or any product of the Windows Server 2003 family, Ftdisk.sys loads anyway and detects all requests to the hard disks.