The HKEY LOCAL MACHINESystem Key

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 also contains a complete copy of these data. The data stored under HKEY_LOCAL_MACHINE\System are organized into Control Sets, each containing a complete set of the settings for device drivers and system services. From time to time, the system administrator may need to edit the items stored under the CurrentControlSet subkey.

Detailed information on the contents of the CurrentControlSet subkey was presented in Chapter 6.

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/2000 saves 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 specifies 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 ControlSet001 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.16, contains four parameters, which describe the control set usage:

Fig. 7.16: The contents of the HKEY_LOCAL_MACHINE\SYSTEM\Select registry key

• 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.

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. Fig. 7.17 shows a typical configuration of the Control subkey.

Fig. 7.17: Typical configuration of the Control Subkey for the CurrentControlSet

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.18), which contain exclusion lists for files and registry keys not to be included 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 to Windows XP. This key relates to the Automated System Recovery process, which in Windows XP has 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)
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. 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.19)
	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.19). Note that the are represented as follows: \REGISTRY\MACHINE\<hivename>, where the <hivename> is the name of appropriate registry hive. Also note the following schema: \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) or the Network and Dial-up Connections option (Windows 2000)
NLS	This subkey contains information on national language support (NLS). You can manage the national language support using the Regional Settings option in Control Panel (Windows NT 4.0) or the Regional Options applet in Control Panel (Windows 2000)
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) 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 this setting has become obsolete SubSystems—this key defines information intended for Windows NT/2000/XP 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 Windows NT/2000 Setup
TimeZoneInformation	This key contains the values that define the 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 NT/2000 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

Fig. 7.18: The contents of the BackupRestore nested key

Fig. 7.19: 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 prepare the ground 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.

Note 

Don't use registry editors to modify this key. If you make an error, neither Windows NT/2000 nor Windows XP 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 as 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 NT/2000/XP 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, and Windows XP). Since Windows 2000/XP implements full-featured Plug and Play support, the contents of the Enum key has become more complicated compared to those of Windows NT 4.0. The screenshot shown in Fig. 7.20 shows the Enum key structure for Windows XP.

Fig. 7.20: 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. Fig. 7.21 shows a typical Root enumerator for Windows XP.

Fig. 7.21: The Root enumerator for a typical Windows XP computer

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/2000 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 specifying 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 when we discussed 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.

 

In Windows XP, 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, there will be the following entry for the parallel port mouse under HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP PointerClass (Fig. 7.22). Notice that the key name is PointerClass and not PointerPort, as it was in Windows NT/2000:

Fig. 7.22: 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.23). At the beginning of the chapter, we discussed this mechanism in the example on video drivers.

Fig. 7.23: 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.

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 (Fig. 7.24) specifies the Alerter service parameters.

Fig. 7.24: The Alerter service parameters in Windows XP registry

Settings such as ErrorControl, Group, DependOnGroup, DependOnService, ImagePath, ObjectName, Start, Tag, and Type manage the 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/XP. This key was first introduced in Windows NT 4.0.

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

Windows NT/2000 creates a default hardware profile based on the original configuration detected during Windows NT/2000 Setup. You can create multiple hardware profiles and select existing profiles at boot time.

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

Fig. 7.25: 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 then 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 appears 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.26), whose value specifies the number corresponding to the key that contains the current hardware profile.

Fig. 7.26: 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 as 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, or Windows XP. On the contrary, this modification will be stored under the following key (Fig. 7.27):

Fig. 7.27: Hardware profiles store only changes introduced to the original configuration

   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 need to be maintained by the operating system.

The Disk Subkey

The HKEY_LOCAL_MACHINE\SYSTEM\Disk subkey has undergone significant changes from its Windows NT 4.0 version. In the Windows NT 4.0 registry, this key contained all the information need to manage the volumes. This key is created by the Disk Administrator built-in Windows NT utility. The key 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, drive mappings, and the data concerning fault-tolerant disk configurations (mirror sets, stripe sets with or without parity), if you've configured 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 and Windows XP 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 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 in your Windows 2000/XP system, Ftdisk.sys loads anyway and detects all requests to the hard disks.