Chapter 23 - Overview of the Windows NT Registry

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

System administrators must meet an enormous challenge in managing hardware, operating systems, and applications on personal computers. In Windows NT, the Registry helps simplify support by providing a secure, unified database that stores configuration data in a hierarchical form. By using the Registry and administrative tools in Windows NT, system administrators can provide local or remote support.

Chapters 23–26 of the Windows NT Workstation Resource Guide describe the Registry and show how to use the information in the Registry for troubleshooting and configuration maintenance.

This chapter presents background information about the structure and contents of the Registry.
Chapter 24, "Registry Editors and Registry Administration," provides details about the tools for viewing and editing Registry entries.
Chapter 25, "Configuration Management and the Registry," provides specific problem-solving techniques that use the Registry.
Chapter 26, "Initialization Files and the Registry," describes how Windows NT uses files such as Win.ini and Config.sys and how this information is mapped to the Registry.

In addition, Regentry.hlp, an online Help file on the Windows NT Workstation Resource Kit CD, lists the Registry values used for tuning and troubleshooting workstations and servers, system components, the network, and the user environment.

Caution Wherever possible, use the administrative tools such as Control Panel and User Manager to make configuration changes, rather than editing the Registry. It is safer to use the administrative tools because these tools are designed to store values properly in the Registry. If you make errors while changing values with a Registry editor, you will not be warned, because the Registry editor applications do not recognize and cannot correct errors in syntax or other semantics.

Editing the Registry directly can cause errors in loading hardware and software and prevent users from being able to log on to the computer.

Getting Started with the Registry Editors

To get the most out of the material in this chapter, run a Registry editing tool so that you can see the contents of the Registry for your computer.

Windows NT 4.0 includes two tools for viewing and editing the Registry, both called Registry Editor. The traditional tool, Regedt32.exe, is documented more thoroughly in these chapters. The new tool, Regedit.exe, has a Windows NT Explorer interface. It has many of the same functions as Regedt32 and an expanded search capability. Both tools are installed automatically when you install Windows NT on any computer.

Figure 23.1 shows the Windows NT Registry as seen by Regedit:

Cc722562.xwr_v01(en-us,TechNet.10).gif

Figure 23.1 The Registry as viewed by Regedit

To run a Registry editor

Start Regedt32.exe or Regedit.exe from Windows NT Explorer, or click Run on the Start menu.

– Or –

Type regedt32 or regedit at the command prompt, and press ENTER.
From the Options menu in Regedt32, click Read Only Mode.

This enables the Regedt32 read-only mode, which protects the Registry contents from unintentional changes while you explore its structure and become familiar with the entries.
Click any folder icon to display the contents of that key.

In Regedit, click Find on the Edit menu to search for keys and subkeys, value entries, and values. In Regedt32, click Find Key on the View menu to search for a key or subkey. However, you cannot search for value entries or values by using the Find Key command in Regedt32.

For more information about Regedt32 and Regedit, click Help Topics on the Help menu of either application.

For details about security and backup measures to take with the Registry and other issues, see Chapter 24, "Registry Editors and Registry Administration."

Figure 23.2 shows the Windows NT Registry as seen by Regedt32.

Cc722562.xwr_v02(en-us,TechNet.10).gif

Figure 23.2 The Windows NT Registry as viewed by Regedt32

The Registry is a database, and Registry Editor displays the five subtrees used to access the contents of the database. The hierarchical structure that appears in Registry Editor looks similar to the hierarchical directory structures in Windows NT Explorer. The information in this chapter helps you understand where specific kinds of information can be found in the Registry and where you should or should not make changes.

In this chapter, the Registry keys are described in the same order as the order in which they appear in the Registry Editor windows. The information on Registry keys in this chapter focuses on those parts of the Registry that a system administrator is most likely to need to view or to change. Some information is provided merely to explain what is stored in certain keys.

The content or location of an individual Registry key on your computer might differ from what is described in these chapters. The Registry configuration depends on the services and software installed, on whether the computer is running Windows NT Workstation or Windows NT Server, and on other factors. However, you can use the general organization described in this chapter to help you understand how to navigate in Registry Editor.

Note Registry entries that system administrators most commonly examine or edit are found under HKEY_LOCAL_MACHINE \System \CurrentControlSet, described later in this chapter. Specific entries are defined in Regentry.hlp, a Help file included on the Windows NT Workstation Resource Kit CD.

How Windows NT Components Use the Registry

Under versions of Windows for MS-DOS, starting the system, connecting to the network, and running applications involves multiple configuration files with some form of synchronization between them. Under Windows NT, the operating system stores and checks the configuration information at only one location—the Registry. Figure 23.3 shows how data is handled by the Windows NT Registry.

Cc722562.xwr_v03(en-us,TechNet.10).gif

Figure 23.3 Data in the Windows NT Registry

Figure 23.4 shows how Windows NT components and applications use the Registry. The explanations in the list that follows provide details.

Cc722562.xwr_v04(en-us,TechNet.10).gif

Figure 23.4 How Registry information is used by Windows NT

Setup. Whenever you run the Windows NT Setup program or other setup programs for applications or hardware, the Setup program adds new configuration data to the Registry. For example, new information is added when you install a new SCSI adapter or change the settings for your video display. Setup also reads information from the Registry to determine whether prerequisite components have been installed.
Recognizer. Each time you start a computer running Windows NT, the Hardware Recognizer places in the Registry a list of the installed hardware it detects. The Hardware Recognizer is a program that runs as part of the Windows NT startup sequence*.* On computers with Intel processors, hardware detection is done by Ntdetect.com and the Windows NT Kernel (Ntoskrnl.exe). On Reduced Instruction Set Computers (RISC), the hardware information is extracted from the ARC (Advanced RISC Computing) firmware.
Windows NT Kernel. During system startup, the Windows NT Kernel extracts information from the Registry, such as which device drivers to load and their load order. The Ntoskrnl.exe program also passes information about itself (such as its version number) to the Registry.
Device drivers. Device drivers send and receive load parameters and configuration data from the Registry. This data is similar to what you might find on the DEVICE= lines in the Config.sys file under MS-DOS. A device driver must report system resources that it uses, such as hardware interrupts and direct memory access (DMA) channels, so the system can add this information to the Registry. Applications and device drivers can read this Registry information to provide users with smart installation and configuration programs.
Administrative tools. The administrative tools in Windows NT, such as those provided in Control Panel and in the Administrative Tools (common) folder, can be used to modify configuration data. The Registry editors are helpful for viewing and occasionally making detailed changes to the system configuration. You can also use Windows NT Diagnostics and the System Policy Editor to view configuration information stored in the Registry and to modify certain Registry keys.

For details, see Chapter 24, "Registry Editors and Registry Administration."

The Registry is analogous to the .ini files used under Windows for MS-DOS, with each key in the Registry similar to a bracketed heading in an .ini file, and entries under the heading similar to values in the Registry. However, Registry keys can contain subkeys; .ini files do not support nested headings. Registry values can also consist of executable code, rather than the simple strings representing values in .ini files. And individual preferences for multiple users of the same computer can be stored in the Registry, which is not possible with .ini files.

Although these chapters focus on using Registry entries instead of using .ini files, some applications (particularly 16-bit Windows-based applications) continue to use .ini files. Windows NT supports .ini files solely for compatibility with those applications and with related tools, such as setup programs. The files Autoexec.bat and Config.sys also still exist in some form to provide compatibility with applications created for MS-DOS and Windows 3.x.

For details about how Windows NT uses such files in conjunction with the Registry, see Chapter 26, "Initialization Files and the Registry."

Registry Structure

This section describes the hierarchical organization of the Registry and defines the overall structure of subtrees, keys, and subkeys. Following this section, details are provided about specific Registry keys.

The Registry Hierarchy

The Registry is structured as a set of subtrees of keys that contain per-computer and per-user databases. The per-computer information includes information about hardware and software installed on the computer. The per-user information includes the information in user profiles, such as desktop settings, individual preferences for certain software, and personal printer and network settings. In versions of Windows for MS-DOS, per-computer information was saved in the Win.ini and System.ini files, but it was not possible to save separate information for individual users.

In the Windows NT Registry, each individual key can contain data items called value entries and can also contain additional subkeys. In the Registry structure, keys are analogous to directories, and the value entries are analogous to files.

Figure 23.5 shows the subtrees of the Windows NT Registry.

Cc722562.xwr_v05(en-us,TechNet.10).gif

Figure 23.5 The subtrees of the Windows NT Registry

Each of these subtrees is described in detail later in this chapter. Each of the root key names begins with "HKEY_" to indicate to software developers that this is a handle that can be used by a program. A handle is a value used to uniquely identify a resource so that a program can access it.

Table 23.1 identifies and defines these subtrees.

Root key name	Description
HKEY_LOCAL_MACHINE	Contains information about the local computer system, including hardware and operating system data such as bus type, system memory, device drivers, and startup control data.
HKEY_CLASSES_ROOT	Contains the associations between applications and file types (by filename extension). It also contains object linking and embedding (OLE) Registry information associated with COM objects, and file-class association data (equivalent to the Registry in Windows for MS-DOS). The entries in this subtree are the same as in HKEY_LOCAL_MACHINE \Software \Classes. For detailed information on HKEY_CLASSES_ROOT, see the OLE Programmer's Reference in the Windows NT 4.0 Software Developer's Kit.
HKEY_CURRENT_CONFIG	Contains configuration data for the current hardware profile. Hardware profiles are sets of changes to the standard configuration of services and devices established by data in the Software and System keys under HKEY_LOCAL_MACHINE. Only the changes appear in HKEY_CURRENT_CONFIG. The entries in this subtree also appear in: HKEY_LOCAL_MACHINE \System \CurrentControlSet \HardwareProfiles \Current.
HKEY_CURRENT_USER	Contains the user profile for the user who is logged on, including environment variables, desktop settings, network connections, printers, and application preferences.
HKEY_USERS	Contains all actively loaded user profiles, including HKEY_CURRENT_USER, and the default profile. Users who are accessing a server remotely do not have profiles under this key on the server; their profiles are loaded into the Registry on their own computers.

Value Entries in the Registry Keys

Registry data is maintained as value entries under the Registry keys. As shown in Figure 23.6, Registry Editor displays data in two panes. The value entries in the right pane are associated with the selected key in the left pane. Click the folders and double-click the entries to see their contents.

Cc722562.xwr_v07(en-us,TechNet.10).gif

Figure 23.6 Terms used to describe items in the Registry Editor window

A value entry has three parts: the name of the value, the data type of the value, and the value itself, which can be data of any length. The three parts of value entries always appear in the following order:

Cc722562.xwr_v08(en-us,TechNet.10).gif

A value entry cannot be larger than about 1 MB. Values from 0 to 0x7fffffff are reserved for definition by the system, and applications are encouraged to use these types. Values from 0x80000000 to 0xffffffff are reserved for use by applications.

Table 23.2 lists the data types defined and used by the system.

Data type	Description
REG_BINARY	Raw binary data. Most hardware component information is stored as binary data, and can be displayed in Registry Editor in hexadecimal format, or displayed by the Windows NT Diagnostics program (Winmsdp.exe) in an easy-to-read format. For example: Component Information : REG_BINARY : 00 00 00...
REG_DWORD	Data represented by a number that is 4 bytes long. Many parameters for device drivers and services are of this type and can be displayed in Registry Editor in binary, hex, or decimal format. For example, entries for service error controls are of this type: ErrorControl : REG_DWORD : 0x1
REG_EXPAND_SZ	An expandable data string, which is text that contains a variable to be replaced when called by an application. For example, for the following value, the string %Systemroot% will be replaced by the actual location of the directory containing the Windows NT system files: File : REG_EXPAND_SZ : %Systemroot%\file.exe
REG_MULTI_SZ	A multiple string. Values that contain lists or multiple values in human-readable text are usually of this type. Entries are separated by NULL characters. For example, the following value entry specifies the binding rules for a network transport: Bindable : REG_MULTI_SZ : dlcDriver dlcDriver non non 50
REG_SZ	A sequence of characters representing human-readable text. For example, a component's description is usually of this type: DisplayName : REG_SZ : Messenger

Hives and Files

The Registry is divided into parts called hives. A hive is a discrete body of keys, subkeys, and values rooted at the top of the Registry hierarchy. Hives are distinguished from other groups of keys in that they are permanent components of the Registry; they are not created dynamically when the system starts and deleted when it stops. Thus, HKEY_LOCAL_MACHINE \Hardware, which is built dynamically by the Hardware Recognizer when Windows NT starts, is not a hive.

Data in the hives is supported by files in the Systemroot\System32\Config and Systemroot\Profiles\Username subdirectories. Figure 23.7 shows the relationship between the hives and their supporting files.

Cc722562.xwr_v09(en-us,TechNet.10).gif

Figure 23.7 Hives and files in the Windows NT Registry

Each hive in the Windows NT Registry is associated with a set of standard files. Table 23.3 lists the standard hives for a computer running Windows NT.

Registry hive	Filenames
HKEY_LOCAL_MACHINE \SAM	Sam, Sam.log, Sam.sav
HKEY_LOCAL_MACHINE \Security	Security, Security.log, Security.sav
HKEY_LOCAL_MACHINE \Software	Software, Software.log, Software.sav
HKEY_LOCAL_MACHINE \System	System, System.alt, System.log, System.sav
HKEY_CURRENT_CONFIG	System, System.alt, System.log, System.sav
HKEY_USERS.DEFAULT	Default, Default.log, Default.sav
(Not associated with a hive)	Userdiff, Userdiff.log
HKEY_CURRENT_USER	Ntuser.dat, Ntuser.dat.log

By default, the supporting files for all hives except HKEY_CURRENT_USER are in Systemroot\System32\Config.

The HKEY_CURRENT_USER support files are stored in all subdirectories of Systemroot\Profiles, except for the All Users subdirectory. The Ntuser.dat files store user profiles; the Ntuser.dat.log files track changes to Ntuser.dat.

The Ntuser and Userdiff files are new to Windows NT 4.0:

The Ntuser.dat file, which stores the user profile, replaces the usernamexxx and adminxxx files in previous versions of Windows NT.
The Ntuser.dat file in Systemroot\Profiles\DefaultUser replaces the Userdef file in previous versions of Windows NT. This profile is used to create the HKEY_CURRENT_USER hive when a new user logs on to Windows NT for the first time.
The Userdiff files, which are only in Systemroot\System32\Config, are not associated with any hive. They are used to upgrade existing user profiles from previous versions of Windows NT to Windows NT 4.0. The user profiles are upgraded the first time the user logs on to Windows NT 4.0.

Four types of files are associated with hives. Table 23.4 describes each file type by its filename extension.

File type	Description
No filename extension	Contains a copy of the hive.
.alt	Contains a backup copy of the critical HKEY_LOCAL_MACHINE \System hive. Only the System key has an .alt file.
.log	Contains a transaction log of changes to the keys and value entries in the hive.
.sav	Contains copies of the hive files as they looked at the end of the text mode stage in Setup. There are .sav files for Software, SAM, Security, System, and .Default. A new feature of Windows NT 4.0 backs up the contents of the hives during setup. Setup has two stages: text mode and graphics mode. The hive is copied to a .sav file after the text-mode stage of setup to protect it from errors that might occur if the graphics-mode stage of setup fails. If setup fails during the graphics-mode stage, only the graphics-mode stage is repeated when the computer is restarted; the .sav file is used to rebuild the hives.

The next section discusses features that, along with the supporting files, help to preserve the integrity of the Windows NT Registry.

Atomicity and Hive Recovery in the Registry

The Registry ensures atomicity of individual actions. This means that any change made to a value (to set, delete, or save) either works or does not work: The result will not be a corrupted combination of the old and new configuration even if the system stops unexpectedly because of power failure, hardware failure, or software problems. For example, if an application sets a value for an entry and the system shuts down while this change is being made, when the system restarts, the entry will have either the old value or the new value, but not a meaningless combination of both values. In addition, the size and time data for the key containing the affected entry will be accurate whether the value was changed or not changed.

Flushing Data

In Windows NT, data is written to the Registry only when a flush occurs, which happens after changed data ages past a few seconds, or when an application intentionally flushes the data to the hard disk.

The system performs the following flush process for all hives (except for the System hive):

All changed data is written to the hive's .log file along with a map of where it is in the hive, and then a flush is performed on the .log file. All changed data has now been written in the .log file.
The first sector of the hive file is marked to indicate that the file is in transition.
The changed data is written to the hive file.
The hive file is marked as completed.

Note If the system shuts down between steps 2 and 4, when the hive is next loaded at startup (unless it's a profile hive that is loaded at logon), the system sees the mark left in step 2, and proceeds to recover the hive using the changes contained in the .log file. That is, the .log files are not used if the hive is not in transition. If the hive is in transition, it cannot be loaded without the .log file.

A different flush process is used for the System hive because it is an important element during system startup and is used too early during startup to be recovered as described in the previous flush process.

The System.alt file contains a copy of the data contained in the System file. During the flush process, changes are marked, written, and then marked as done. Then the same flush process is followed for the System.alt file. If there is a power failure, hardware failure, or software problems at any point during the process, either the System or System.alt file contains the correct information.

The System.alt file is similar to a .log file except that at load time, rather than having to reapply the logged changes, the system just switches to System.alt. The System.alt file is not needed unless the System hive is in transition.

User Profile Hives

Each time a new user logs on to a computer, a new hive is created for that user with a separate file for the user profile. The system administrator can copy a user profile file to a different directory and view, repair, or copy entries to another computer by using Registry Editor. For specific information on this feature, see "Managing User Profiles Through the Registry" in Chapter 25, "Configuration Management and the Registry." For information about the hive for the default profile, see "HKEY_USERS" later in this chapter.

Registry Size Limit

Registry data is stored in the paged pool, an area of physical memory used for system data that can be written to disk when not in use. The RegistrySizeLimit value establishes the maximum amount of paged pool space (and disk paging file space) that can be consumed by Registry data from all applications. It is designed to prevent the Registry from consuming space needed by processes.

The RegistrySizeLimit value establishes a maximum size for the Registry. It does not allocate space in the paged pool, nor does it assure that the space will be available if needed.

By default, RegistrySizeLimit is set to 25 percent of the size of the paged pool. When the paged pool size changes, either because it is adjusted by Windows NT or because an administrator changes it, the value of RegistrySizeLimit changes, too. (Typically, the paged pool is set at 32 MB, so the RegistrySizeLimit value is 8 MB.)

The system ensures that the minimum value for RegistrySizeLimit is 4 MB, and the maximum is approximately 80 percent of the PagedPoolSize value. Thus, the paged pool is limited to a maximum size of 128 MB, and the RegistrySizeLimit value cannot exceed 102 MB (80 percent of 128 MB).

To view or change the value of RegistrySizeLimit, edit the entry under the following subkey:

HKEY_LOCAL_MACHINE \System \CurrentControlSet \Control

RegistrySizeLimit must have a type of REG_DWORD and a data length of 4 bytes, or it will be ignored. The RegistrySizeLimit value is approximate.

To view or change the size of the paged pool, use the PagedPoolSize value entry under the following subkey:

HKEY_LOCAL_MACHINE \System \CurrentControlSet \Control \Session Manager\Memory Management

The space controlled by RegistrySizeLimit includes the hive space, as well as some of the Registry's run-time structures. Other Registry run-time structures are protected by their own size limits or by other means.

To ensure that a user can always start the system and edit the Registry, the Registry is not subject to the value set in RegistrySizeLimit until after the first successful loading of a hive (that is, the loading of a user profile). For more details about RegistrySizeLimit, see Regentry.hlp, the Registry Help file on the Windows NT Workstation Resource Kit CD.

HKEY_LOCAL_MACHINE

HKEY_LOCAL_MACHINE contains the configuration data for the local computer. The information in this database is used by applications, device drivers, and the Windows NT system to determine configuration data for the local computer, regardless of which user is logged on and what software is in use.

HKEY_LOCAL_MACHINE contains five keys, as listed briefly in Table 23.5. The rest of this section describes these keys.

Note You can read information in any of these keys, but you can add or change information only in the Software and System keys.

Key name	Contents
Hardware	The database that describes the physical hardware in the computer, the way device drivers use that hardware, and mappings and related data that link kernel-mode drivers with user-mode code. All data in this key is recreated each time the system is started. The Description subkey describes the actual computer hardware. The DeviceMap subkey contains miscellaneous data in formats specific to particular classes of drivers. The ResourceMap subkey describes which device drivers claim which hardware resources. The Windows NT Diagnostics program (Winmsdp.exe) can report on its contents in an easy-to-read form.
SAM	The directory services database of security information for user and group accounts, and for the domains in Windows NT Server. (SAM is the Security Account Manager, now known as the directory services database.)
Security	The database that contains the local security policy, such as specific user rights. This key is used only by the Windows NT security subsystem.
Software	The per-computer software database. This key contains data about software installed on the local computer, along with various items of miscellaneous configuration data.
System	The database that controls system startup, device driver loading, Windows NT services, and operating system behavior.

By convention, if similar data exists under HKEY_CURRENT_USER and under HKEY_LOCAL_MACHINE, the data in HKEY_CURRENT_USER takes precedence. However, values in this key can also extend (rather than replace) data in HKEY_LOCAL_MACHINE. Also, some items (such as device driver loading entries) are meaningless if they occur outside of HKEY_LOCAL_MACHINE.

HKEY_LOCAL_MACHINE \Hardware Key

The HKEY_LOCAL_MACHINE \Hardware key contains the hardware data in the Registry that is computed at system startup. This includes information about hardware components on the system board and about the interrupts hooked by specific hardware devices.

The Hardware key contains distinct and important sets of data in three subkeys—Description, DeviceMap, and ResourceMap. These keys are described in the following sections.

All information in HKEY_LOCAL_MACHINE \Hardware is volatile, which means that the settings are computed each time the system is started and then discarded when the system stops. Applications and device drivers use this subtree to read information about the system components, store data directly into the DeviceMap subkey, and store data indirectly into the ResourceMap subkey.

Cc722562.xwr_v12(en-us,TechNet.10).gif

Tip Do not try to edit the data in HKEY_LOCAL_MACHINE \Hardware; much of the information appears in binary format, making it difficult to decipher.

To view data about a computer's hardware in an easy-to-read format, run Windows NT Diagnostics, click the Services tab, and then click the Devices button (in the lower right corner of the tab). Windows NT Diagnostics extracts the information from the Registry and renders it in a more readable format.

Description Subkey

The Description subkey under HKEY_LOCAL_MACHINE \Hardware displays information from the hardware database built by the firmware, the Hardware Recognizer (Ntdetect.com), and the Windows NT Executive, which manages the interface between the Kernel and the environment subsystems:

On RISC-based computers, this hardware database is a copy of the ARC configuration database in the firmware.
On a computer with an Intel processor platform, this database consists of the data found by Ntdetect.com and Ntoskernel.exe.
On computers that are not PC-compatible, the manufacturer provides its own Hardware Recognizer.

The Hardware Recognizer for Intel-based computers detects the following items:

Bus/adapter type	Video adapter
Keyboard	Floating-point coprocessor
SCSI adapters	Mouse
Communication ports	Floppy drives
Machine ID	Parallel ports

Note Network adapter cards are not detected as part of startup; they are detected either during Windows NT Setup or when you install a new network adapter. To install a network adapter, in Control Panel, double-click Network, click the Adapters tab, then click Add. For details, see "Network Settings in the Registry," later in this chapter.

The key HKEY_LOCAL_MACHINE \Hardware \Description \SystemMultifunctionAdapter contains several other subkeys, each corresponding to specific bus controllers on the local computer. Each of these subkeys describes a class (or type) of controller, including controllers for disk drives, display, keyboard, parallel ports, pointing devices, serial ports, and SCSI devices. The subkey's path describes the type of component. The numbering for hardware components is zero-based, which means that, for example, the first (or only) disk controller appears under the 0 subkey.

The name of the MultifunctionAdapter subkey depends on the bus type. For example, for ISA and MCA buses the subkey name appears as MultifunctionAdapter. For EISA buses, the subkey name is EisaAdapter, and for TurboChannel buses, the subkey name is TcAdapter. Figure 23.8 shows a MultifunctionAdapter subkey.

Cc722562.xwr_v13(en-us,TechNet.10).gif

Figure 23.8 A MultifunctionAdapter subkey for an ISA or MCA bus

For each detected hardware component, the optional Component Information and Configuration Data value entries store version and configuration data in binary format. The Identifier entry contains the name of a component, if specified. For details on these value entries, see Regentry.hlp, a Help file on the Windows NT Workstation Resource Kit CD.

DeviceMap Subkey

In the HKEY_LOCAL_MACHINE \Hardware \DeviceMapDevice key, each Device subkey contains one or more values to specify the location in the Registry for specific driver information for that kind of component.

Figure 23.9 shows an example of the DeviceMap subkey and the value entry for a selected device name.

Cc722562.xwr_v14(en-us,TechNet.10).gif

Figure 23.9 A DeviceMap subkey showing the value entry for a serial mouse device

The value for each Device subkey describes an actual port name or the path for a Service subkey in HKEY_LOCAL_MACHINE \System \ControlSetnnn\Services, which contains information about a device driver. That Service subkey contains the information a system administrator might need for troubleshooting and is also the information presented about the device by Windows NT Diagnostics.

Figure 23.10 shows DeviceMap entries for a computer that has multiple SCSI adapters.

Cc722562.xwr_v15(en-us,TechNet.10).gif

Figure 23.10 A DeviceMap subkey with value entries for multiple SCSI adapters

ResourceMap Subkey

The ResourceMap subkey under HKEY_LOCAL_MACHINE \Hardware maps device drivers to resources that the drivers use. Each ResourceMap subkey contains data reported by the device driver about its use of I/O ports, I/O memory addresses, interrupts, direct memory access (DMA) channels, and so on. The data in the ResourceMap subkey is volatile, meaning that the subkey is recreated each time you start Windows NT.

Under the ResourceMap subkey, there are DeviceClass subkeys for the general class (or type) of devices. Each of these subkeys contains one or more DriverName subkeys with information about a specific driver. For example, in Figure 23.11, Sermouse is the DriverName subkey under the PointerPort DeviceClass subkey. (The driver names in these subkeys match the services listed in HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services.)

Cc722562.xwr_v16(en-us,TechNet.10).gif

Figure 23.11 A DeviceMap subkey showing the value entry for a device

OwnerMap Subkey

The OwnerMap subkey under HKEY_LOCAL_MACHINE \Hardware appears in the Registry only when certain types of device bus, such as a PCI device bus, are installed on the computer. The OwnerMap subkey contains operating system data to associate drivers of a specified type with devices of the same type on each installed bus. This subkey is new to Windows NT 4.0. Figure 23.12 shows a typical configuration of OwnerMap.

Cc722562.xwr_v17(en-us,TechNet.10).gif

Figure 23.12 The OwnerMap subkey

HKEY_LOCAL_MACHINE \SAM Key

The HKEY_LOCAL_MACHINE \SAM key contains the user and group account information in the directory services database (formerly known as the Security Account Manager, or SAM) for the local computer. For a computer that is running Windows NT Server, this key also contains security information for the domain. This information appears in User Manager. Also, on computers with NTFS partitions, you can view and edit security information for a file in Windows NT Explorer. (From the File menu, click Properties, then click the Security tab. Click Permissions to modify user and group permissions in the directory services database.)

This key is mapped to HKEY_LOCAL_MACHINE \Security \SAM, so changes made in one Registry key also appear in the other.

Caution Do not edit the value entries in this subkey by using Registry Editor. The values are in binary format. Errors in this database may prevent users from being able to log on to the computer.

System administrators should use User Manager (Windows NT Workstation) or User Manager for Domains (Windows NT Server) to add or remove users, to change information about accounts, or to change security information for the local computer or for the domain.

HKEY_LOCAL_MACHINE \Security Key

The HKEY_LOCAL_MACHINE \Security key contains security information for the local computer, including user rights, password policy, and the membership of local groups, as set in User Manager.

The subkey HKEY_LOCAL_MACHINE \Security \SAM is mapped to HKEY_LOCAL_MACHINE \SAM, so changes made in one automatically appear in the other.

If you want to change global group membership or other security-related items, use User Manager or User Manager for Domains.

Caution The information in this database is in binary format and should not be changed by using Registry Editor. Errors in this database may prevent users from being able to log on to the computer.

HKEY_LOCAL_MACHINE \Software Key

The HKEY_LOCAL_MACHINE \Software key contains specific configuration information about software on the local computer. The entries under this key, which applies to any user of the computer, show which software is installed on the computer.

HKEY_LOCAL_MACHINE \Software \Classes contains data to associate applications with file types (by filename extension). It also includes Registry information associated with COM objects. The data under the Classes subkey is also reflected in HKEY_CLASSES_ROOT.

Figure 23.13 shows how the HKEY_LOCAL_MACHINE \Software subkey appears on one machine.

Cc722562.xwr_v18(en-us,TechNet.10).gif

Figure 23.13 The HKEY_LOCAL_MACHINE \Software subkey

The HKEY_LOCAL_MACHINE \Software subtree contains several subkeys. The Classes, Program Groups, and Secure subkeys are described here, plus general information about the various Description subkeys that can appear in a Registry.

Classes Subkey

The Classes subkey contains two types of subkeys:

Filename-extension subkeys associate applications with file types by their filename extension. These subkeys contain information you add by using the File Types tab in Windows NT Explorer, information added during installation of Windows-based applications, and information about applications installed by Windows NT.

Figure 23.14 shows where data is stored to associate .avi files with an application.

Figure 23.14 Filename-association subkeys in the Classes subkey
Class-definition subkeys contain Registry information associated with Component Object Model (COM) objects. The data in these subkeys specifies the shell and OLE (COM) properties of an object. If an application supports dynamic data exchange (DDE), the Shell subkey can contain Open and Print subkeys that define DDE commands for opening and printing files, similar to the information stored in the Registry database under versions of Windows for MS-DOS.

Figure 23.15 shows the shell properties of Regfile.exe, the executable file for Regedit. In this example, the service (or friendly) name of Regedit is specified.

Figure 23.15 Shell properties for Regfile.exe in the Classes subkey

Important The COM information in the Registry must be created by the COM application. Do not change this information by using Registry Editor. To change the association between a file type and an application, click Options on the View menu in Windows NT Explorer, then use the File Types tab in the Options dialog box.

Description Subkeys

The HKEY_LOCAL_MACHINE \SoftwareDescription subkeys contain the names and version numbers of the software installed on the local computer. (Information about the configuration of these applications is stored on a per-user basis under HKEY_CURRENT_USER.)

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

HKEY_LOCAL_MACHINE \Software \DescriptionCompanyName\ProductName\Version

Figure 23.16 shows some entries under the subkey for Microsoft (a CompanyName), which contains entries for the service software installed on the computer:

Cc722562.xwr_v34(en-us,TechNet.10).gif

Figure 23.16 Description subkey entries

Note The information in each subkey is added by the related application. Do not edit entries in these subkeys unless directed to do so by your application vendor.

Microsoft Subkey

The HKEY_LOCAL_MACHINE \Software \Microsoft subkey contains configuration settings for Microsoft software installed on the computer.

The Windows NT\CurrentVersion subkey is of particular interest. This subkey contains information about software that supports services built into Windows NT, as well as data about the version and type of the current release (multiprocessor versus uniprocessor). For example, it is possible to run a Windows NT uniprocessor kernel on a multiprocessor computer, but you do not get any multiprocessor benefits by doing so. To find out which kernel type is running on a computer, see the data in the Registry under the Windows NT\CurrentVersion subkey.

Program Groups Subkey

The Program Groups subkey under HKEY_LOCAL_MACHINE \Software is redefined in Windows NT 4.0. In previous versions of Windows NT, it contained a list of the program groups used by all users of the local computer. In Windows NT 4.0, program groups have been replaced by the Windows NT Explorer directory structure. Now, this subkey is used only to record—as a yes/no, 0x1/0x0 value—whether all former program groups have been converted to the new directory structure.

The ConvertedToLinks value entry indicates whether the program groups were converted. A value of 1 (0x1) indicates that the conversion is complete.

When Windows NT 4.0 is installed on a computer that has never run Windows NT, there are no subkeys under the Program Groups subkey. However, upgraded versions can still contain binary data for common program groups that appear as Program Groups subkeys.

Secure Subkey

The Secure subkey provides a convenient place for applications to store configuration information that should be changed only by an administrator.

Windows 3.1 Migration Status Subkey

The Windows 3.1 Migration Status subkey contains data if the computer has been upgraded from Windows 3.x to Windows NT 4.0. The values in this subkey indicate whether .ini and Reg.dat files have migrated successfully to the Windows NT 4.0 format. If this subkey is deleted, Windows NT again attempts to migrate the files when the system is restarted.

There is also a Windows 3.1 Migration Status subkey under HKEY_CURRENT_USER. It tracks the migration of Program Group (.grp) files to the Windows NT Explorer format.

For more information about Windows 3.x migration, see Part 6, Chapter 27, "Compatibility and Migration: Windows 3.x and Windows 95* *," in this book.

HKEY_LOCAL_MACHINE \System Key

All startup-related data that must be stored (rather than computed during startup) is saved in the System hive. A complete copy of the data is also stored in the System.alt file. The data in HKEY_LOCAL_MACHINE \System—which is the System hive—is organized into control sets that contain a complete set of parameters for devices and services as described in this section. You might occasionally need to change entries in the CurrentControlSet subkey, as described in Chapter 25, "Configuration Management and the Registry."

Figure 23.17 shows the structure of this subtree.

Cc722562.xwr_v21(en-us,TechNet.10).gif

Figure 23.17 The HKEY_LOCAL_MACHINE \System key

The following sections describe the HKEY_LOCAL_MACHINE \System subkeys.

ControlSetnnn, Select, and CurrentControlSet Subkeys

The Registry, particularly data in the System hive, is essential to starting the system. To help ensure that the system can always be started, a kind of backup version is kept, which allows you to undo any configuration changes that did not have the intended effect. This section describes how it works.

Figure 23.18 shows the structure of subkeys under the HKEY_LOCAL_MACHINE \System key.

Cc722562.xwr_v22(en-us,TechNet.10).gif

Figure 23.18 Subkeys under HKEY_LOCAL_MACHINE \System

All of the data required to control startup is gathered into subkeys called control sets in the Registry. Each control set has four subkeys:

The Control subkey contains configuration data used to control the system, such as the computer's network name and the subsystems to start.
The Enum subkey contains hardware configuration data for devices and drivers loaded by Windows NT.
The Hardware Profiles subkey contains configuration data for drivers and devices specific to a hardware profile. Users can create multiple hardware profiles for each control set. Data appears under the Hardware Profiles subkey only when it differs from the standard settings for drivers and devices. The current hardware profile in the CurrentControlSet subkey also appears in HKEY_CURRENT_CONFIG.
The Services subkey contains a list of drivers, file systems, user-mode service programs, and virtual hardware keys. Its data controls which services are loaded and their load order. The data in the Services subkey also controls how the services call each other.

Multiple control sets are saved as subkeys of HKEY_LOCAL_MACHINE \System under names such as ControlSet001 and ControlSet003. Although as many as four control sets (numbered 000–003) can appear, there are usually two sets. This is similar to having multiple sets of Config.sys files under MS-DOS—a current file and a backup copy known to start the system correctly. However, all of the work of creating and maintaining backups is done automatically by the system.

The Select subkey consists of four value entries that describe how the control sets are used:

Default specifies the number of the control set (for example, 001 = ControlSet001) that the system will use at next startup, barring an error or manual invocation of the LastKnownGood control set by the user.
Current specifies the number of the control set actually used to start the system this time.
LastKnownGood specifies the number of the control set that is a clean copy of the last control set that actually worked.
Failed specifies the control set that was replaced if the LastKnownGood control set was used to start the system this time. You can examine this control set to learn why the replacement was required.

The Clone subkey contains the last control set used to start the system. If the start was successful ("good"), the contents of the Clone become the LastKnownGood control set.

The CurrentControlSet subkey is not the root of an actual control set; rather, it is a symbolic link to the control set indicated by the value of Current. It is there so that constant paths can be used to refer to subkeys in the currently used control set, even though the name of that control set may change.

These multiple control sets are used to allow an escape from various problems. Each time the system starts, the control set used to start is saved (under HKEY_LOCAL_MACHINE \System \Clone). If the startup is declared to be "good," the LastKnownGood control set is discarded, and the Clone subkey is copied to replace it. An administrator can change the requirements for a startup to be classified as "good," but a startup is typically declared to be "good" if no severe or critical errors occurred while starting the services and if at least one user logged on successfully.

The LastKnownGood configuration is used when the user chooses LastKnownGood from the Hardware Profile/Configuration Recovery menu during startup or if startup fails (is not "good"). When this happens, a new control set is created by copying the LastKnownGood control set and the values of the entries in HKEY_LOCAL_MACHINE \System \Select are changed to point to different control sets:

The control set identified as Default is identified as Failed.
The control set identified as LastKnownGood is identified as Default.

User profile data is stored elsewhere and is therefore unaffected.

Tip When you start Windows NT, you can choose which control set the system uses. At the Boot Loader command prompt, select Windows NT, then press the SPACEBAR. The Hardware Profile/Configuration Recovery menu appears. Follow the instructions on the screen to select the control set or LastKnownGood configuration from the menu.

To find out whether Default or LastKnownGood was used, see the values in the Select subkey.

To modify the information stored in these subkeys, use the Devices, Network, Server, and Services options in Control Panel, or use Server Manager.

To modify the configuration by using Registry Editor, make changes under the CurrentControlSet subkey.

The Control and Services subkeys found in each control set are described in the following sections.

Control Subkey for All Control Sets

The Control subkey contains startup parameters for the system, including information about the subsystems to load, computer-dependent environment variables, the size and location of the paging files, and so on. Figure 23.19 shows the typical Control subkeys, and Table 23.6 describes the contents of some typical subkeys.

Cc722562.xwr_v23(en-us,TechNet.10).gif

Figure 23.19 A typical configuration of the Control subkey for a control set

Subkey	Contents
BootVerificationProgram	A value that can be set to define a nonstandard mechanism to declare system startup as "good," as described in Chapter 25, "Configuration Management and the Registry."
ComputerName	The names of the default and active computers, stored in two subkeys, ComputerName and ActiveComputerName. To set the computer name, use the Network option in Control Panel.
GroupOrderList	Specifies the order in which to load services for all groups that have one, used in combination with Tags. ServiceGroupOrder specifies the order for loading groups.
ServiceGroupOrder	Specifies the order in which to load various groups of services. Order within groups is specified by using Tags and GroupOrderList.
HiveList	The location of the files that contain Registry information. This value should be maintained only by the system.
Keyboard Layout	The DLLs for the keyboard language used as the default layout, plus a subkey named DosKeybCodes that lists the other available keyboard layouts. To set keyboard layout, use the Input Locales tab under the Keyboard option in Control Panel.
Lsa	The authentication package for the local security authority. This value should be maintained only by the system—errors can prevent anyone from being able to log on to the computer.
NetworkProvider	Can contain two subkeys, Active and Order, that specify the network provider and the order in which to load providers. Control settings for network providers by using the Network option in Control Panel.
Nls	Information on national language support in three subkeys: CodePage, Language, and OEMLocale. Set preferences about language and locale in Windows NT by using the Regional Settings option in Control Panel.
Print	Information about the current printers and printing environment, contained in several subkeys: Environments, which contains subkeys defining drivers and print processors for system environments such as Windows NT on Digital Alpha, Windows NT on MIPS Rx4000, and Windows NT on Intel-based computers. Monitors, which can contain subkeys with data for specific network printing monitors. Printers, which can contain subkeys describing printer parameters for each installed printer. Providers, which can contain subkeys describing DLLs for network print services. To change printing parameters, click the Start button, point to Settings, then point to the Printers folder.
PriorityControl	The Win32 priority separation. Set this value only by using the System option in Control Panel.
ProductOptions	The product type, such as Windows NT. These values should be maintained only by the system.
Session Manager	Global variables used by Session Manager and these subkeys: DOSDevices, which defines the MS-DOS devices AUX, MAILSLOT, NUL, PIPE, PRN, and UNC. Environment, which defines the ComSpec, Path, Os2LibPath, and WinDir variables. To set user environment variables, in Control Panel double-click System. To change or add to the computer's default path, or add default system environment variables, change the values in this subkey. For more details, see Regentry.hlp, a Registry Help file on the Windows NT Workstation Resource Kit CD. FileRenameOperations, which is used during startup to rename certain files so that they can be replaced. These values should be maintained only by the system. KnownDLLs, which defines the directories and filenames for the Session Manager DLLs. These values should be maintained only by the system. MemoryManagement, which defines paging options. Define the paging file by using the System option in Control Panel. SubSystems, which defines information for the Windows NT subsystems. These values should be maintained only by the system.
Setup	Hardware setup options. These values should be maintained only by the system. Users can make choices by running Windows NT Setup.
TimeZoneInformation	Values for time zone information. Set these values by using the Date/Time option in Control Panel.
VirtualDeviceDrivers	Virtual device drivers. These values should be maintained only by the system.
Windows	Paths for the Windows NT directory and system directory. These values should be maintained only by the system.
WOW	Options for 16-bit Windows-based applications running under Windows NT. These settings should be maintained only by the system.

Enum Subkey for All Control Sets

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

This subkey, new with Windows NT 4.0, was one of several keys added to HKEY_LOCAL_MACHINE to enable Windows NT to access and control drivers and devices in ways similar to those used in Windows 95. (The methods are similar—but not the same, because the architecture of Windows NT differs from that of Windows 95.)

The changes reflected in these new keys prepare Windows NT to run the new generation of Plug and Play drivers and devices implemented in Windows 95. Plug and Play drivers are not included in Windows NT 4.0, but when the drivers become available, these changes will enable them to be implemented with fewer changes to the operating system.

Warning: Do not use a Registry editor to change the data in this key. Errors in this key can prevent Windows NT from detecting or operating hardware devices necessary to the operation of the computer. Windows NT protects this key from changes by all users, including administrators. Administrators can change the permissions on the key, but this is strongly discouraged. In your applications, use the standard Device Installer or Config Manager API to change data in the Enum subkeys.

By using the Device Installer or Config Manager API, you can enable applications to modify the data in Enum subkeys without including the path name of the Registry key in the application code. The Windows NT Registry has a different structure than the Registry in Windows 95. Because of this, if your application refers to this Registry key by path name, the application will not run on both Windows NT and Windows 95.

In general, the Enum subkey contains configuration data for devices. The subkeys under Enum represent a device hierarchy (or tree) that starts at a tree root (the top) and ends at the lowest branch with configuration data for a specific instance of a device, such as the keyboard on the local computer.

The Enum subkey itself is merely a container. It is not associated with any value entries. There are at least two subkeys immediately under Enum: Htree represents the hardware tree; the remaining keys represent enumerators, the means by which Windows NT learned about a device.

The Htree\Root\0 subkey is a reserved space in the Registry that represents the root (the top) of the hardware tree.. It contains the AttachedComponents value entry, which lists devices rooted at the top of the hardware tree.

Figure 23.20 shows the Htree\Root\0 subkey and its AttachedComponents value listing.

Cc722562.xwr_v24(en-us,TechNet.10).gif

Figure 23.20 AttachedComponents value listing under Htree\Root\0

The remaining subkeys immediately under Enum represent enumerators and contain the subkeys of devices that have the same enumerator. For Plug and Play devices, the enumerator is the device bus on which the device runs, such as PCI or ISAPNP. A default enumerator, Root, is used for non–Plug and Play devices (known as legacy devices), which are enumerated by other parts of the system.

Figure 23.21 shows the Root enumerator of a typical computer running Windows NT.

Cc722562.xwr_v25(en-us,TechNet.10).gif

Figure 23.21 Typical contents of a Root enumerator subkey

Each enumerator subkey, such as Root, contains subkeys that represent device types or models. The device type subkeys, in turn, contain the subkeys that represent devices of that type. The device type subkeys for each enumerator vary depending on the devices installed on the computer.

The name of each device type subkey indicates whether it is a Plug and Play device or a legacy (non–Plug and Play) device.

For Plug and Play devices and for all modems, the name of the device type subkey varies with the device. A modem is a special case because its driver, Modem.sys, includes some Plug and Play functionality. For example, on a computer with more than one modem, Windows NT can detect an individual instance of each modem even when all modems share the same driver.
For most legacy devices, Windows NT builds a device-type ID of the form LEGACY_DriverName. This subkey contains data for all devices controlled by that driver.
For legacy keyboards and mouse devices, the device type ID typically begins with *PNP followed by an alphanumeric string. The Windows NT drivers for keyboards and mouse devices have some limited Plug and Play functionality. For example, Windows NT accesses keyboards and mouse devices in some of the same ways as it accesses Plug and Play devices.

The subkeys under the device type are the device instance subkeys. These subkeys contain value entries that specify the configuration of a device. However, the device(s) to which the value entries apply depend on whether the device is a Plug and Play device or a legacy device.

For Plug and Play devices (including modems), each device type subkey can contain multiple device instance subkeys. The name of each device instance subkey uniquely identifies a particular device to Windows NT, and the value entries in the subkey apply only to that device. Because of this, users and applications can configure each instance of a device individually.
For legacy devices, there is only one key—0000—to represent all instances of devices on the computer that are controlled by the driver for which the subkey is named. The configuration data in this subkey applies to all of the devices; they cannot be configured separately by using Windows NT.

The value entries and subkeys under the device instance subkeys vary with the device and its driver. For more information, see Regentry.hlp, the Registry Help file on the Windows NT Workstation Resource Kit CD.

Services Subkey for All Control Sets

The Services subkey in each control set lists all device drivers, file system drivers, and Win32 service drivers that can be loaded by the Boot Loader, the I/O Manager, and the Service Control Manager. The Services subkey also contains subkeys that are static descriptions of hardware to which drivers can be attached. Table 23.7 describes some typical Services subkeys for a computer running Windows NT.

Entries that appear under the DeviceMap subkeys include values that refer to entries in the Services subkey in the control set. For example, for a serial mouse, the following entry might appear under the DeviceMap\PointerPort subkey in HKEY_LOCAL_MACHINE \Hardware:

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

A related Services subkey named Sermouse defines values for the serial mouse driver. Figure 23.22 shows a typical configuration of the Sermouse subkey.

Cc722562.xwr_v26(en-us,TechNet.10).gif

Figure 23.22 The Sermouse subkey

To view this information in a more readable format, use Windows NT Diagnostics or the Control Panel.

To find detailed information about a driver, in Windows NT Diagnostics, click the Services tab, click the Devices button (in the lower right corner), then double-click the name of the device.
To change startup settings and other parameters for a driver, in Control Panel double-click Devices.

For suggestions on using the information in Windows NT Diagnostics and the Control Panel for troubleshooting, see Chapter 25, "Configuration Management and the Registry."

Each subkey includes several standard (but optional) entries, as shown in Figure 23.23, where Alerter is the name of a Windows NT service.

Cc722562.xwr_v27(en-us,TechNet.10).gif

Figure 23.23 Subkey for the Alerter service under Services

The value entries that govern the behavior of a service include ErrorControl, Group, DependOnGroup, DependOnService, ImagePath, ObjectName, Start, Tag, and Type. For definitions of these value entries, see Regentry.hlp, the Registry Help file on the Windows NT Workstation Resource Kit CD.

The optional Linkage subkey specifies the binding options for the driver by using the Bind and Export values.

The OtherDependencies value that appears in the Linkage subkey for some services enables nodes to be loaded in an order related to other specific nodes with which they are closely associated. For example, the NBF transport depends on an NDIS driver. Therefore, to load the NBF protocol stack successfully, an NDIS network card driver must be loaded first. For details about loading order dependencies for network components, see "Dependency Handling for Network Components," later in this chapter.

The Parameters subkey (optional for some Services subkeys such as an adapter entry) contains a set of values to be passed to the driver. These values vary for each device driver. Figure 23.24 shows parameters for the serial mouse driver.

Cc722562.xwr_v28(en-us,TechNet.10).gif

Figure 23.24 Parameters subkey for the serial mouse driver

Because the entries in the Services list are Registry keys, no assumptions can be made about their order in an enumeration, so services can explicitly specify load ordering by grouping services and drivers in order by type. For example, the SCSI port driver can be loaded before any of the miniport drivers. The ordering is specified under the \Control\ServiceGroupOrder subkey in a control set.

Settings for the drivers that appear under the Services subkeys can be changed by using the Devices, Network, or Services options in Control Panel or, for network services, User Manager for Domains in Windows NT. Specific parameters for drivers and services are described in online Help for the Registry.

Table 23.7 describes typical Services subkeys for a Windows NT–based computer.

Service name	Description
Abiosdsk	Primary disk1
Ahaxxx	Adaptec SCSI adapters1
Alerter	Alerter service for the workstation3
AtDisk	Primary disk driver for non-SCSI hard disks1
Ati	ATI video display1
Beep	Base sound driver1
Browser	Computer browser used by Workstation and Server services3
BusLogic	BusLogic SCSI adapter1
Busmouse	Bus mouse pointer1
Cdaudio	Filter1
Cdfs	SCSI CD-ROM file system driver1
Cirrus	Cirrus Logic video display1
ClipSrv	ClipBook (Network DDE service)3
Cpqarray	Compaq array driver (no additional Registry values)
Dell_DGX	Dell DGX video display1
Diskperf	Disk Performance Monitoring Statistics Driver1
DptScsi	DPT SCSI adapter1
Et4000	Tseng ET4000 video display1
EventLog	Event log service3
Fastfat	FAT file system driver1
Fd16_700	Future Domain MCS 600/700, TMC-7000ex, 800-series SCSI adapters1
Floppy	Primary disk1
Ftdisk	Filter1
i8042pt	Keyboard driver1
Inport	Microsoft InPort Mouse pointer1
Jazzgxxx	Video display1
Jzvxl484	Video display1
Kbdclss	Keyboard class driver1
LanmanServer	Server service3
Lanman Workstation	Workstation service3
Messenger	Messenger service for workstation3
Mouclass	Mouse class driver1
Mup	Network1
Nbf	NetBEUI transport protocol1, 2
Ncrxxx	NCR SCSI controllers and adapters1
NetBIOS	NetBIOS transport interface1, 2
NetDDE et al.	Network DDE and Network DDE DSDM3
NetDetect	Network detection1
NetLogon	Network logon for workstation3
Ntfs	NTFS file system driver1
Null	Base driver for null port1
Oliscsi	Olivetti SCSI adapter1
Parallel	Parallel port1
Qv	Qvision video display driver1
RAS	Remote Access Service3
Rdr	Network redirector1
Replicator	Directory replicator for workstation and server3
RPCLocator	Remote Procedure Call (RPC) locator (name service provider)3
RPCSS	Remote Procedure Call (RPC) service3
S3	S3 video display1
Schedule	Network schedule service3
Scsixxxx	SCSI class devices, which do not add parameters to the Registry, including Scsicdrm, Scsidisk, Scsiflip, Scsiprnt, and Scsiscan
Serial	Serial port1
Sermouse	Serial mouse1
Sgikbmou	Silicon Graphics keyboard and mouse driver1
Sgirex	Silicon Graphics video display driver1
Simbad	Filter1
Sparrow	SCSI adapter1
Spock	SCSI adapter1
Srv	Network server3
T128, T13B	Trantor SCSI adapters1
Trident	Trident video display1
UBxxx	Ungermann-Bass NDIS drivers1, 3
Ultraxxx	UltraStore SCSI adapters1
UPS	Uninterruptible power supply (UPS)3, 4
V7vram	Video Seven VRAM video display1
Vga	VGA video display1
Videoprt	Video display1
Wd33c93	Maynard SCSI adapter1
Wdvga	Western Digital/Paradise video display1
Xga	IBM XGA video display1

1 Change settings for this driver by using the Devices option in Control Panel.

2 Change settings for this driver by using the Network option in Control Panel.

3 Change settings for this driver by using the Services option in Control Panel or by using Server Manager in Windows NT Services.

4 Change settings for this driver by using the UPS option in Control Panel.

Hardware Profiles Subkey for All Control Sets

The Hardware Profiles subkey in each control set contains the configuration data for all hardware profiles in a Windows NT–based system. This subkey is new to Windows NT 4.0.

A hardware profile is a set of changes to the standard configuration of devices and services (including drivers and Win32 services) loaded by Windows NT when the system starts. For example, a hardware profile can include an instruction to disable (that is, not load) a driver, or an instruction to Windows NT to not connect an undocked laptop computer to the network. Because of the instructions in this subkey, users can modify the service configuration for a particular use while preserving the standard configuration unchanged for more general uses.

Windows NT creates a default hardware profile (called Original Configuration). But users can create multiple hardware profiles and, when Windows NT starts, select from them the settings they want .

To create hardware profiles, use the System, Services, and Devices options in Control Panel. For more information on creating hardware profiles, double-click System in Control Panel, click the Hardward Profiles tab and open Help.

Figure 23.25 shows the Hardware Profiles subkey under CurrentControlSet.

Cc722562.xwr_v29(en-us,TechNet.10).gif

Figure 23.25 The Hardware Profiles subkey for CurrentControlSet

Each numbered subkey under Hardware Profiles contains the configuration data for one hardware profile on the system. If there is more than one hardware profile, the system identifies a subkey as current when the user chooses it during startup. The Current subkey is a symbolic link to one of the numbered subkeys.

The HKEY_CURRENT_CONFIG subtree is an alias pointing to the Hardware Profiles\Current subkey of CurrentControlSet; the contents of the Current subkey appear in the HKEY_CURRENT_CONFIG subtree.

Tip To determine which numbered subkey under Hardware Profiles represents the current hardware profile, see HKEY_LOCAL_MACHINE \System \CurrentControlSet \Control \IDConfigDB subkey. The value of CurrentConfig in the IDConfigDB subkey corresponds to the number of the subkey that contains the current hardware profile.

The data in each hardware profile subkey consists of profile-specific modifications to the standard service configuration. Only data that has been changed from the standard configuration is stored there, but organized in the same structure as the standard configuration. The standard configuration is defined by data stored throughout the Software and System subkeys of HKEY_LOCAL_MACHINE. Hence, the structure of a hardware profile is modeled on the structure of HKEY_LOCAL_MACHINE and can be thought of as a limited or condensed version of HKEY_LOCAL_MACHINE .

Figure 23.26 demonstrates the similar structures of HKEY_LOCAL_MACHINE and the subkeys under Hardware Profiles\0001.

Cc722562.xwr_v30(en-us,TechNet.10).gif

Figure 23.26 HKEY_LOCAL_MACHINE and Hardware Profiles\0001 subkeys

When a hardware profile specifies a change to a value entry in the Software or System subkeys of HKEY_LOCAL_MACHINE, the original value in the Software or System subkey is not changed; instead that change is stored in the analogous subkey of Hardware Profiles\Number.

For example, if a user creates a hardware profile in which the Diskperf driver (which collects performance statistics for disks) is not loaded, the HKEY_LOCAL_MACHINE \System \CurrentControlSet \Enum \Root \LEGACY_DISPERF subkey is not changed. Instead, the change is stored in HKEY_LOCAL_MACHINE \System\CurrentControlSet\Hardware Profiles\Number\System\CurrentControlSet\Enum\Root\LEGACY_DISPERF.

The subkeys of a hardware profile store the same kind of information as their counterparts in the Software and System subkeys of HKEY_LOCAL_MACHINE, but the hardware profile subkeys store changes only. This means that the driver, service, and device settings loaded when a hardware profile is chosen consist of those specified in the Software and System subkeys of HKEY_LOCAL_MACHINE, as modified by the data in the Software and System subkeys of the hardware profile.

For information about the subkeys of a hardware profile, see the descriptions of their analogs in the Software and System subkeys of HKEY_LOCAL_MACHINE. For information about the value entries in these subkeys, see Regentry.hlp, the Registry Help file on the Windows NT Workstation Resource Kit CD.

Setup Subkey

The Setup subkey under HKEY_LOCAL_MACHINE \System is used internally by Windows NT for the Setup program. Do not change these value entries. These settings should be maintained only by the system.

HKEY_CLASSES_ROOT

HKEY_CLASSES_ROOT contains information about file associations and data associated with COM objects. As shown in Figure 23.27, this is the same data as in the Classes subkey under HKEY_LOCAL_MACHINE \Software.

Cc722562.xwr_v31(en-us,TechNet.10).gif

Figure 23.27 HKEY_CLASSES_ROOT and the HKEY_LOCAL_MACHINE \Software \Classes subkey

The sole purpose for HKEY_CLASSES_ROOT is to provide compatibility with the Windows 3.1 registration database.

HKEY_CLASSES_ROOT contains the data that associates file types (by filename extension) with the applications that support them. Do not change file associations by using Registry Editor. Instead, to change a file association, in Windows NT Explorer, from the Options menu, click View, then click the File Types tab.

For more information about HKEY_CLASSES_ROOT, see the OLE Programmer's Reference in the Windows NT 4.0 Software Developer's Kit.

HKEY_CURRENT_CONFIG

The HKEY_CURRENT_CONFIG subtree, new to Windows NT 4.0, contains configuration data for the hardware profile currently in use on the computer. This subtree is actually an alias pointing to HKEY_LOCAL_MACHINE \System \CurrentControlSet \Hardware Profiles\Current. The contents of the Hardware Profiles\Current subkey appear in this subtree.

HKEY_CURRENT_CONFIG was added to the Windows NT 4.0 Registry to be compatible with the HKEY_CURRENT_CONFIG subtree in the Windows 95 Registry. Because it was added to Windows NT, applications that use the HKEY_CURRENT_CONFIG subtree can run on both Windows 95 and Windows NT.

Warning: The Windows NT Registry has a different structure than the Windows 95 Registry. Hardware data is stored in different locations in the two registries. In your applications, use the standard Device Installer API or Config Manager API to change data in the Class and Enum subkeys of HKEY_CURRENT_CONFIG. If your application refers to these Registry keys by path, it will not run on both Windows NT and Windows 95.

Figure 23.28 displays the structure of HKEY_CURRENT_CONFIG and demonstrates that HKEY_CURRENT_CONFIG is just another way to view the contents of HKEY_LOCAL_MACHINE \System \CurrentControlSet \Hardware Profiles\Current.

Cc722562.xwr_v32(en-us,TechNet.10).gif

Figure 23.28 HKEY_CURRENT_CONFIG and the Hardware Profile\Current subkey of HKEY_LOCAL_MACHINE

HKEY_CURRENT_CONFIG contains data that describes the current hardware profile.

A hardware profile is a set of changes to the standard configuration of devices and services (including drivers and Win32 services) loaded by Windows NT when the system starts. For example, a hardware profile can include an instruction to disable (that is, not load) a driver, or an instruction to Windows NT to not connect an undocked laptop computer to the network. Because of the instructions in this subkey, users can modify the service configuration for a particular use while preserving the standard configuration unchanged for more general uses.

The current hardware profile is the one used to start Windows NT. Users can create multiple hardware profiles and, when Windows NT starts, select from them the settings they want. To create hardware profiles, use the System, Services, and Device options in Control Panel. For more information on creating hardware profiles, double-click System in Control Panel, click the Hardware Profiles tab and open Help.

In the Registry, hardware profiles are stored in the Hardware Profiles subkey in all control sets under HKEY_LOCAL_MACHINE \System. The current hardware profile appears in the Current subkey under each Hardware Profiles subkey, and the subkey under CurrentControlSet appears in HKEY_CURRENT_CONFIG.

The data in HKEY_CURRENT_CONFIG consists of profile-specific modifications to the standard service configuration. This standard configuration is defined by data stored throughout the Software and System subkeys of HKEY_LOCAL_MACHINE. Hence, the structure of HKEY_CURRENT_CONFIG is modeled on the structure of HKEY_LOCAL_MACHINE and can be thought of as a limited or condensed version of HKEY_LOCAL_MACHINE.

When the current hardware profile specifies a change to a value entry in the Software or System subkeys of HKEY_LOCAL_MACHINE, the original value in the Software or System subkey is not changed; instead that change is stored in the analogous subkey of HKEY_CURRENT_CONFIG.

Note If you change a hardware profile by using a Registry editor, most drivers will be unable to read those changes. Use Control Panel to create and configure hardware profiles.

For example, if a user creates a hardware profile in which the Diskperf driver (which collects performance statistics for disks) is not loaded, the HKEY_LOCAL_MACHINE \System \CurrentControlSet \Enum \Root \LEGACY_DISPERF subkey is not changed. Instead, the change is stored in HKEY_LOCAL_MACHINE \System \CurrentControlSet \Hardware Profiles\Number\System\CurrentControlSet\Enum\Root\LEGACY_DISPERF*.*

Figure 23.29 shows the subkeys in this example.

Cc722562.xwr_v33(en-us,TechNet.10).gif

Figure 23.29 The Diskperf driver subkeys in HKEY_CURRENT_CONFIG and HKEY_LOCAL_MACHINE

For more information on the contents of HKEY_CURRENT_CONFIG, see "Hardware Profiles Subkey for All Control Sets" in "HKEY_LOCAL_MACHINE," earlier in this chapter.

HKEY_CURRENT_USER

HKEY_CURRENT_USER contains the database that describes the user profile for the user who is currently logged on to the local computer. A user profile contains information that defines the appearance and behavior of the individual user's desktop, network connections, and other environment settings. A user profile ensures that Windows NT looks and acts the same at any computer where that user logs on, if that person's profile is available at that computer or on the same domain in Windows NT Server.

HKEY_CURRENT_USER contains all the information necessary to set up a particular user environment on the computer. This includes information about settings such as application preferences, screen colors, and other personal preferences and security rights. Many of these settings are similar to the information that was stored in the Win.ini file under Windows for MS-DOS.

HKEY_CURRENT_USER includes the default subkeys described in Table 23.8. For details about the contents of subkeys in HKEY_CURRENT_USER, see Regentry.hlp, the Registry Help file on the Windows NT Workstation Resource Kit CD.

Subkey	Contents
AppEvents	Subkeys that define application events, including the sound scheme, the set of relationships between user actions and the sound produced by the computer.
Console	Subkeys that define the options and window size for a console (the interface between the user-mode and character-mode applications). This includes settings for the Windows NT command prompt. These settings should be changed by using the commands in the Control menu of each non–Windows-based application. (The subkey for the command prompt does not appear unless the font or screen colors have been changed by the current user.)
Control Panel	Subkeys that correspond to parameters that can be changed by using the options in Control Panel. This includes information that was stored in the Win.ini and Control.ini files under Windows for MS-DOS.
Environment	Value entries that correspond to the current user's settings for environment variables. This includes information that was stored in the Autoexec.bat file under MS-DOS. Values should be set by using the System option in Control Panel.
Keyboard Layout	Subkeys that specify the language used for the current keyboard layout. To change the language associated with the keyboard, use the Input Locales tab under the Keyboard option in Control Panel.
Network	This key is no longer used. (In previous versions of Windows NT, it stored persistent connections. Persistent connections are now stored in HKEY_CURRENT_USER \Software \Microsoft \Windows NT\CurrentVersion\Network\Persistent Connections.)
Printers	Subkeys that describe the printers installed for the current user. To change printer values, click the Start button, point to Settings, then point to the Printers folder.
Software	Subkeys that describe the current user's configurable settings for installed software that the user can use. This information has the same structure as HKEY_LOCAL_MACHINE \Software. This information contains application-specific information that was stored in the Win.ini file or private initialization files under Windows for MS-DOS.
UNICODE Program Groups	This subkey is not used in Windows NT 4.0. If the computer was upgraded to Windows NT 4.0 from a previous version of Windows NT, this subkey might contain old subkeys in binary form. However, neither this subkey nor any subkeys it contains holds valid data used by Windows NT 4.0.
Windows 3.1 Migrations Status	This subkey contains data only if the computer has been upgraded from Windows 3.x to Windows NT 4.0. It contains the subkeys that indicate whether Program Group (.grp) and .ini files have been successfully converted to the Windows NT 4.0 format. If you delete this key, Windows NT tries to convert the files again when the system restarts. There is also a Windows 3.1 Migration Status subkey under HKEY_LOCAL_MACHINE \Software that tracks the conversion of .ini and Reg.dat files to the Windows NT format.

Whenever similar data exists in the HKEY_LOCAL_MACHINE subtree and the HKEY_CURRENT_USER subtree, the data in HKEY_CURRENT_USER takes precedence, as described earlier in "HKEY_LOCAL_MACHINE." The most significant example is environment variables, where variables defined for the user who is currently logged on take precedence over system variables. Use the System option in Control Panel to define system variables.

HKEY_CURRENT_USER is mapped to HKEY_USERSID_#, where SID_# is the Security ID string of the current user. The Windows NT logon process builds a user's personal profile environment based upon what it finds in HKEY_USERSID_#. If no such data is available, HKEY_CURRENT_USER is built from the data in Systemroot\Profiles\Default User\Ntuser.dat.

Note To find the name of the file that goes with a hive, see the HiveList subkey in HKEY_LOCAL_MACHINE \System \CurrentControlSet \Control. To find which hive file goes with a user profile (whether or not the user is logged on), see the ProfileList subkey under HKEY_LOCAL_MACHINE \Software \Microsoft \Windows NT\CurrentVersion. To locate a specific subkey quickly, you can use the Find Key command from the View menu in Registry Editor.

HKEY_USERS

HKEY_USERS contains all actively loaded user profiles. HKEY_USERS has at least two keys: .DEFAULT and the Security ID string for the user who is currently logged on. The information in the .DEFAULT subkey is used when no users are logged on to the computer (the ctrl+alt+delete login prompt is displayed).

The .DEFAULT key contains the same subkeys as in HKEY_CURRENT_USER. These are described in Table 23.9. For details about the contents of subkeys in HKEY_USERS, see Regentry.hlp, the Registry Help file on the Windows NT Workstation Resource Kit CD.

To delete profiles from a computer, click Delete User Profiles on the Options menu in Windows NT Setup.

Network Settings in the Registry

When a network component is installed, information is added to the Registry. Each network component is represented in two distinct areas of the Registry:

Software registration subkeys for the component's driver and adapter card under HKEY_LOCAL_MACHINE \Software
Service registration keys for the component's driver and adapter under HKEY_LOCAL_MACHINE \System

The following sections describe the general organization and content of the software and service registration information for network components and then conclude with information about bindings for network components and dependency handling.

Note The information in this section is provided so that you can find entries in the Registry easily. Do not change settings for network adapters and supporting software by directly editing values in the Registry. Instead, use the Adapters tab under the Network option in Control Panel.

Network Component Types in the Registry

Table 23.9 describes the network component types.

Component type	Meaning
Adapter	A piece of hardware
Driver	A software component associated directly with a piece of hardware
Transport	A software component used by services
Service	A software component providing capability directly to user applications
Basic	A token used to represent a fundamental class name (that is, a class with no parent)

Each type of network component requires subkeys for both software and services. Therefore, the installation of a single network card usually results in the creation of four distinct subkeys in the Registry:

The software registration subkey for the driver, found in HKEY_LOCAL_MACHINE \SoftwareCompany\ProductName\Version.

For example, the path for the driver for an Etherlink adapter is HKEY_LOCAL_MACHINE \Software \Microsoft \Elinkii \CurrentVersion.
The software registration subkey for the network adapter card, found in HKEY_LOCAL_MACHINE \Software \Microsoft \Windows NT\CurrentVersion\NetworkCards\Netcard#.
The service registration subkey for the driver, found in HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services.
The service registration subkey for the network adapter card, found in HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services.

Software Registration Information for Network Components

Because installation of a network adapter card results in separate Registry entries for the driver and for the adapter, the Software key contains several subkeys to describe the network component. For each network component, a special subkey named NetRules is created in the appropriate driver or adapter registration subkeys. The NetRules subkey identifies the network component as part of the network ensemble.

For example, the standard software registration entry for the Etherlink II driver appears under the path HKEY_LOCAL_MACHINE \Software \Microsoft \Elinkii \CurrentVersion.

The standard entries for the driver might include the following values:

Description = 3Com Etherlink II Adapter Driver
InstallDate = 0x2a4e01c5
...
RefCount = 0x1
ServiceName = Elnkii
SoftwareType = driver
Title = 3Com Etherlink II Adapter Driver

And under the Etherlink II driver's related NetRules subkey, these value entries might appear:

bindable = elnkiiDriver elnkiiAdapter non exclusive
bindform = "ElnkIISys" yes no container
class = REG_MULTI_SZ "elnkiiDriver basic" 
Infname = OEMNADE2.INF
InfOption = ELNKII
type = elnkiiSys ndisDriver elnkiiDriver
use = driver

The Etherlink adapter is described in a NetworkCards subkey under the path HKEY_LOCAL_MACHINE \Software \Microsoft \Windows NT\CurrentVersion\NetworkCards\Netcard#.

The standard entries for the adapter might include these values:

Description = 3Com Etherlink II Adapter 
InstallDate = 0x2a4e01c5
Manufacturer = Microsoft
ProductName = Elnkii
ServiceName = Elnkii02
Title = [01] 3Com Etherlink II Adapter

And these value entries might appear under the adapter's related NetRules subkey:

bindform = "Elnkii02" yes yes container
class = "elnkiiAdapter basic" 
Infname = OEMNADE2.INF
InfOption = ELNKII
type = elnkii elnkiiAdapter

The value entries for the NetRules subkeys are defined in the online Help for the Registry. The information in the main entries for network adapters and drivers is maintained by the system and should not be changed by users.

Service Registration Information for Network Components

The HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services subkey is the service registration area that contains the information used to load a network component into memory. These subkeys contain required information, such as the location of the executable file, the service type, and its start criterion.

Each network component's software registration information (as described in the previous section) contains an entry named ServiceName, whose value is the name of the service corresponding to the network component. This name acts as a symbolic link to the CurrentControlSet\Services parameters.

Some network components are actually sets of services, each of which has its own subkey in the Services subkey. There is usually a "main" service, with the other services listed as its dependencies.

For example, as shown in the previous section, the Etherlink driver's ServiceName value is Elnkii, and this name would appear as a Services subkey that defines the location of the driver file, dependencies, and other startup information. The Elnkii subkey in turn contains other subkeys that define the parameters and linkage rules for the driver.

The Etherlink adapter's ServiceName value is Elnkii02, which also appears as a Services subkey that defines linkage rules for bindings plus physical parameters of the network card, such as its I/O address and interrupt request (IRQ) number, as specified on the Adapters tab under the Network option in Control Panel.

The value entries for the subkeys describing adapters and drivers are defined in "Registry Entries for Network Adapter Cards" in the online Help for the Registry.

Bindings for Network Components

For the networking software in a computer to operate properly, several different pieces of software must be loaded, and their relationships with other components must be established. These relationships are often called bindings. To determine the complete set of optimal bindings among an ensemble of configured network components, the system checks the following information in the Registry:

The set of network components to be configured
The types of network components in this set
The constraining parameters for the network components and their bindings
The possible bindings that could occur
The proper way to inform each network component about its bindings

During system startup, the CurrentControlSet\Services subkey is checked for binding information for each service. If any is found, a Linkage subkey is created, and values are stored. For example, these two strings might appear in a value entry under the CurrentControlSet\Services\LanmanWorkstation\Linkage subkey:

Bind = \Device\Nbf_Elnkii01 \Device\Nbf_Elnkii02

This entry describes the binding information used by the Windows NT Redirector when two separate network cards are present. Each network card's symbolic name is suffixed with a network card index number. This name is joined to the name of the transport through which the network card is accessed. The names are generated by the system according to the constraints defined by the network component's rules.

Bindings have a usability requirement that means the binding must terminate either at an adapter (that is, a physical device) or at a logical endpoint, which is simply a software component that manages all further interconnection information internally. This requirement avoids loading software components that can never be of actual use. For example, a user might have a running network and then choose to remove the adapter card. Without the usability restriction, the bindings still connect components and prepare them for loading even though the network is entirely unusable.

The following example uses Nbf.sys and Srv.sys in an ensemble with two Etherlink II network cards and an IBM Token Ring card. First, in the values in the CurrentControlSet\Services\Nbf\Linkage subkey are the following:

Bind= "\Device\ElnkII1"
"\Device\ElnkII2"
"\Device\IbmTok1"
Export= "\Device\Nbf\ElnkII1"
"\Device\Nbf\ElnkII2"
"\Device\Nbf\IbmTok1"
Route= "ElnkIISys ElnkII1"
"ElnkIISys ElnkII2"
"IbmtokSys IbmTok1"

Under the CurrentControlSet\Services\Srv\Linkage subkey, the following might appear:

Bind= "\Device\Nbf\ElnkII1"
"\Device\Nbf\ElnkII2"
"\Device\Nbf\IbmTok1"
Export= "\Device\Srv\Nbf\ElnkII1"
"\Device\Srv\Nbf\ElnkII2"
"\Device\Srv\Nbf\IbmTok1"
Route= "Nbf ElnkIISys ElnkII1"
"Nbf ElnkIISys ElnkII2"
"Nbf IbmtokSys IbmTok1"

The names in the Bind and Export entries are based upon the object names defined in the component's NetRules subkey; these value entries can therefore be different from the actual names of the services, although in the previous example, for the sake of clarity, they are not. The names in the Route entry are the names of the Services subkeys comprising the full downward route through the bindings protocol.

When the system finishes computing the bindings for network components and the results are stored in the Registry, some network components might need to be informed of changes that occurred. For example, TCP/IP must prompt the user for an IP address for any network adapter that has been newly configured. If the NetRules subkey for a network component has a value entry named Review set to a nonzero value, the .inf file for the network component will be checked every time the bindings are changed.

Dependency Handling for Network Components

Services can be dependent upon other services or drivers, which can be dependent upon others, and so on. The system can establish these types of dependencies:

Specific dependencies, which are represented by the names of the services upon which a service is dependent
Group dependencies
Static dependencies, which are required in all circumstances

Specific Dependencies

A specific dependency is simply the name of a necessary service. By default, the system generates explicit names for all dependent services discovered during bindings generation. Specific dependencies are marked in the Registry as a value of the Use entry under the component's NetRules subkey.

For example, assume the Workstation service is dependent upon NBF. NBF is connected to two adapter cards and so is dependent upon their drivers. The system marks NBF as dependent upon the two network card drivers and marks the Workstation service as dependent upon the network card drivers and NBF.

Group Dependencies

It often happens that a service should be loaded if any member of a set of dependencies successfully loads. In the previous example, the Workstation service fails to load if either of the network card drivers fails to initialize.

Groups are used to support this approach. Any service (driver, transport, or others) can identify itself as being a member of a service group. All Windows NT network card drivers, for example, are treated as members of the group NDIS.

Group dependencies are marked in the Registry as a value of the Use entry under the component's NetRules subkey. Groups are symbolic names listed in the CurrentControlSet\Control\GroupOrderList subkey.

Static Dependencies

A static dependency is a required service in all circumstances and is unrelated to how the system otherwise determines bindings.

When the system computes dependencies, it discards any previously listed dependencies. To guarantee that a service is always configured to be dependent upon another service, you can create the value entry OtherDependencies under the component's Linkage subkey. The OtherDependencies value is of type REG_MULTI_SZ, so it can contain the names of as many services as needed.