- Figure 7.14: The contents of the HKEY_LOCAL_MACHINE\SYSTEM\Select registry
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
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
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
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
By default, it contains a single value entry named Plug ' Play
(data type REG_MULTI_SZ, value
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
BootVerificationProgra This value can be used to specify a non-standard mechanism of
m 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
- Table 7.2: Typical subkeys of the Control Key for All Control Sets
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
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\, where the is
the name of the appropriate registry hive. Also note the following
\Device\HarddiskVolumeN\%SystemRoot%\System32\Config\, 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.
- Table 7.2: Typical subkeys of the Control Key for All Control Sets
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
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'
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
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
- Table 7.2: Typical subkeys of the Control Key for All Control Sets
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
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
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
WOW The settings stored under this key define options for 16-bit
Windows applications. Once again, these settings should be
- Table 7.2: Typical subkeys of the Control Key for All Control Sets
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
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
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
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_ 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:
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
- Figure 7.18: An example of the contents of the
HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\PointerClass registry key in
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
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
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
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
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
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
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
- 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:
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
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.