Chapter 23 - Overview of the Windows NT Registry
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.
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:
Figure 23.1 The Registry as viewed by Regedit
To run a Registry editor
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.
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.
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.
Figure 23.4 How Registry information is used by Windows NT
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."
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.
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.
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.
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:
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.
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.
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.
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:
Four types of files are associated with hives. Table 23.4 describes each file type by its filename extension.
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.
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):
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 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.
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.
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.
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:
The Hardware Recognizer for Intel-based computers detects the following items:
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.
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.
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.
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.
Figure 23.10 A DeviceMap subkey with value entries for multiple SCSI adapters
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.)
Figure 23.11 A DeviceMap subkey showing the value entry for a device
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.
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.
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.
The Classes subkey contains two types of subkeys:
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.
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:
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.
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.
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.
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.
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:
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:
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:
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.
Figure 23.19 A typical configuration of the Control subkey for a control set
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.
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.
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.
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.
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.
Figure 23.22 The Sermouse subkey
To view this information in a more readable format, use Windows NT Diagnostics or the Control Panel.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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 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.
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 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:
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.
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:
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 =  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:
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:
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.
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.
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.