Xem mẫu

  1. Figure 7.8: An example of the contents of the DeviceN nested key for the device driver subkey under HKEY_LOCAL_MACHINE\SYSTEM\ControlSetnnn\Services Depending on the video driver implementation, this key may contain a variety of parameters, including the VgaCompatible standard setting, which is set to FALSE for most modern drivers. If the parameter is set to FALSE, the driver is based on the MS VGA miniport driver. The following REG_BINARY settings under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\{56652C39- 3E1C-4A83-AD68-1CF58F0EDEE9}\0000: HardwareInformation.AdapterString, HardwareInformation.BiosString, HardwareInformation.ChipType, HardwareInformation.Crc32, HardwareInformation.DacType HardwareInformation.MemorySize contain hardware information displayed by administrative utilities. Notice that similar settings are also present in Windows NT/2000 registries, but under different locations. When Windows GUI starts, the system reads the video settings contained under the following registry key (Fig. 7.9): HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet Hardware Profiles\Current\System\CurrentControlSet\Control\VIDEO {56652C39-3E1C-4A83-AD68-1CF58F0EDEE9}\0000
  2. Figure 7.9: Registry settings that specify the video mode After reading these settings, the system checks whether the display driver supporting the specified mode is present. As soon as the appropriate driver has been found, the startup procedure continues. What happens, though, if the system can't find an appropriate driver? The answer's simple: the system will use standard VGA mode (16 colors). Thus, we have considered the usage of the HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP information for searching for specific device driver data. We've used the video adapter as an example, but the system uses a similar algorithm for locating the appropriate drivers for any other device. To summarize, let's note that the HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP data describes either an actual port name or the path to the appropriate subkey under HKEY_LOCAL_MACHINE\System\ControlSetnnn\Services. This, in turn, contains the necessary information on the device driver. Sometimes, system administrators may need this information for troubleshooting purposes. It should be noted again that administrative utilities, such as Device Manager, display the same information presented in user-friendly format rather than raw binary data. The RESOURCEMAP Subkey The RESOURCEMAP subkey under HKEY_LOCAL_MACHINE\HARDWARE maps device drivers and hardware resources allocated to these drivers. Each setting stored within the RESOURCEMAP key contains the data reported by the device driver concerning memory addresses, IRQs, and DMA channels requested by respective drivers. All the data contained within this key is volatile. Windows NT/2000/XP and Windows Server 2003 recreate the key during every system startup. Because Windows 2000/XP and Windows Server 2003 implement full-featured Plug and Play support and include a new kernel-mode component (Plug and Play Manager), the contents of the HKEY_LOCAL_MACHINE\HARDWARE\RESOURCEMAP registry key are different for Windows 2000/XP/Windows Server 2003 from what they are for Windows NT 4.0. In the Windows NT 4.0 registry, the RESOURCEMAP key contains
  3. multiple subkeys, which are used to store information on specific device driver classes. Each of these keys contains one or more subkeys that store information related to individual drivers. The RESOURCEMAP key in Windows 2000\Windows XP\Windows Server 2003 registries looks somewhat different (Fig. 7.10). The kernel-mode Plug and Play Manager now controls all the hardware devices. Because of this, the data concerning system resources is stored under the following registry key: HKEY_LOCAL_MACHINE\HARDWARE\RESOURCEMAP\PnP Manager\PnpManager. Figure 7.10: The RESOURCEMAP key in Windows XP/Windows Server 2003 The HKEY_LOCAL_MACHINE\SAM Key For computers that are not joined to a domain, the HKEY_LOCAL_MACHINE\SAM registry key contains information on local user and group accounts stored in the directory database (which was formerly known as the SAM database). For Windows 2000 Server and Windows Server 2003 computers joined to a domain, this key also contains security data for domain users and groups. This key references the HKEY_LOCAL_MACHINE\Security\SAM key, and any modification introduced into one of these keys is immediately introduced into another one. Note Starting with Windows 2000, domain controllers both in Windows 2000 and Windows Server 2003 domains store security data in the Active Directory database file (Ntds.dit). However, SAM database is still preserved for storing local security information on servers that are not joined to a domain, as well as for backward compatibility with the existing Windows NT 4.0 domains. Besides this, it is used for restoring Active Directory information when the user selects the Directory Services Restore Mode (Windows domain controllers only option from the Windows Advanced Startup Options menu during system boot.
  4. Default security settings both in Windows 2000 Server and in Windows Server 2003 prevent users (even those with administrative permissions) from viewing the contents of this registry key. More detailed information on this topic will be provided in Chapter 9. The HKEY_LOCAL_MACHINE\SECURITY Key The HKEY_LOCAL_MACHINE\SECURITY registry key contains information about the security subsystem on the local computer, including user rights and permissions, password policies, and local group membership. All of this information is specified using administrative utilities such as User Manager (Windows NT 4.0 Workstation), User Manager for Domains (Windows NT 4.0 Server), User Management MMC snap-in (Windows 2000 Professional and Windows XP) and Active Directory Users and Computers (Windows 2000 and Windows Server 2003 domain controllers). The HKEY_LOCAL_MACHINE\SECURITY\SAM key references the HKEY_LOCAL_MACHINE\SAM key; because of this, any modification introduced into one of these keys will immediately appear within another one. The HKEY_LOCAL_MACHINE\SOFTWARE Key The HKEY_LOCAL_MACHINE\SOFTWARE registry key contains configuration data concerning the software installed on the local computer. Settings that reside under this key contain settings for the software installed on the local PC and are in force for any user who's logged on to the local system. The HKEY_LOCAL_MACHINE\SOFTWARE\Classes key contains filename extension association data. It also stores registry data associated to COM objects. The data stored under the Classes key are also displayed under HKEY_CLASSES_ROOT. Fig. 7.11 shows the typical contents of the HKEY_LOCAL_MACHINE\Software registry key. Figure 7.11: Typical contents of the HKEY_LOCAL_MACHINE\SOFTWARE key
  5. The HKEY_LOCAL_MACHINE\SOFTWARE subtree contains several nested keys, the most important being the Classes, Program Groups, and Secure subkeys. Later in this chapter, we'll discuss several subkeys that may appear in the registry. The Classes Subkey The parameters contained under this key are the same as the parameters stored under HKEY_CLASSES_ROOT. Detailed information on the contents of this key is provided in the "OLE Programmer's Reference" document included with the Windows Platform Software Development Kit. The HKEY_LOCAL_MACHINE\SOFTWARE\Classes key contains subkeys of the following types: Subkeys of the type associate applications installed on local computers with file types (identified by filename extensions). These subkeys contain data that you can add using the File Types tab of the Folder Options window, as well as information added by the Setup programs that install Windows applications. subkeys. These subkeys contain information associated with COM objects. The data contained within these keys specify the shell and OLE (COM) properties for specific objects. If the application supports DDE (Dynamic Data Exchange), the Shell subkey may, in turn, contain other subkeys such as Open and Print. The subkeys define DDE commands for opening and printing files. Notice that the information contained under these keys is very similar to that which is stored in the registry database of previous Windows versions, such as Windows 3.1x. Note The COM object information contained in the registry must be created by an application supporting COM. Direct registry editing can't be considered the easiest method of editing the information. If you need to perform this task in Windows NT 4.0, select the Options command from the View menu in Windows NT Explorer, then go to the File Types tab of the Options dialog. If you need to perform the same task in Windows 2000, Windows XP, or one of the Windows Server 2003 products, start the Folder Options applet from the Control Panel, or select the Folder Options command from the Tools menu in Windows Explorer; then go to the File Types tab in the Folder Options window. The Description Subkeys The HKEY_LOCAL_MACHINE\Software\Description keys contain names and version numbers of the software installed on the local computer. (Configuration settings specified for individual users are stored under HKEY_CURRENT_USER.) During installation, applications register this information in the following form:
  6. HKEY_LOCAL_MACHINE\Software\Description\CompanyName\ProductName\Versio n. Note Version information for each application must be added to the registry by the appropriate application. Don't edit values under these keys except when the application vendor instructs you to do so. An example illustrating how the registration information of an application (AvantGo in our case) is stored under the HKEY_LOCAL_MACHINE\SOFTWARE registry key is presented in Fig. 7.12. Figure 7.12: An example of application registration information under HKEY_LOCAL_MACHINE\Software registry key The Microsoft Subkey The HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft subkey contains configuration settings for Microsoft software products installed on the local computer. One of the most important subkeys under HKLM\SOFTWARE\Microsoft is the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion key. This key contains information on the software that supports Windows built-in services and the type and version number of the current OS installation (for example, the data specify whether the system has a multiprocessor kernel). Obviously, a single-processor kernel will work on a multi-processor computer, but it won't provide any advantages over the single-processor configuration. To identify the kernel type, view the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion (Fig. 7.13).
  7. Figure 7.13: The HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion registry key Note When speaking about the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion registry key, it is simply impossible not to mention one of the most appreciated performance enhancements introduced with Windows XP and Windows Server 2003. These newer operating systems provide built-in user mode heap-leak detection. The problem is that poorly written or miscoded applications can "leak" heap memory. In versions released earlier than Windows XP, special tools were needed to help identify the cause of the memory leak when this situation arose. To enable leak detection, set the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion Image File Execution Options\] "ShutdownFlags"="3" The Program Groups Subkey The Program Groups subkey, residing under the HKEY_LOCAL_MACHINE\Software registry key, has undergone some changes in comparison to previous versions of Windows NT (Windows NT 3.51 and earlier). In Windows NT 4.0, this key was redefined. In earlier Windows NT versions, the key contained a list of program groups used by all users of the local computer. In Windows NT 4.0 and its successors, this key is only used to specify whether or not all the program groups that existed in the previous operating system (for upgraded systems) were converted to a new format. The Program Groups key contains a single entry named ConvertedToLinks, which determines whether the program groups have been converted. If the ConvertedToLinks value is set to 1, the conversion has been completed successfully. If you install a fresh copy of the operating system rather than upgrade an earlier version to Windows XP or Windows Server 2003, the Program Groups subkey won't contain any
  8. subkeys. If you've performed an upgrade, the Program Groups key will contain subkeys containing binary data defining general program groups. The Secure Subkey Applications can use the Secure subkey for storing configuration settings that can only be changed by the system administrator. The Windows 3.1 Migration Status Subkey The Windows 3.1 Migration Status subkey contains data only if the current operating system was installed as an upgrade from Windows 3.1. The parameters contained in this key specify if all INI files and the registry database (Reg.dat) were successfully converted to the Windows NT 4.0\Windows 2000 registry format. If you delete this key, Windows will make another attempt to convert these files after rebooting. Windows 3.1 Migration Status also exists under HKEY_CURRENT_USER. It specifies the conversion status of the program groups files (GRP files) to the Windows Explorer program group format. The HKEY_LOCAL_MACHINE\System Key All the data related to the startup process, which the system needs to read rather than calculate, are stored in the System hive. The System.alt file (existing in Windows 2000 and earlier) also contains complete copies of these data. The data stored under HKEY_LOCAL_MACHINE\System are organized into Control Sets, each containing a complete set of parameters for device drivers and system services. Now and then, the system administrator may need to edit the items stored under the CurrentControlSet subkey. Chapter 6 contains detailed information on the contents of the CurrentControlSet subkey. The ControlSetnnn, Select, and CurrentControlSet Subkeys The registry, in particular the System hive, has the most important role at system startup. To guarantee that the system will start, Windows NT-based operating systems save the backup copy, allowing you to discard any configuration modifications that have led to unexpected results. In this section, we'll discuss the mechanism used for this purpose. All data necessary to control the startup process are organized in subkeys called Control sets. Each control set contains the following four subkeys:
  9. The Control subkey that contains configuration settings used for system management, including the network name of the local computer and subsystems that should start. The Enum subkey contains hardware data, including data on the hardware devices and drivers to be loaded. The Hardware Profiles subkey contains hardware settings and driver configurations related to the individual hardware profile. You can create individual hardware profiles for each control set. The Hardware Profiles subkey will contain any data if only the data are different from the standard settings for device drivers and system services. The current hardware profile stored under CurrentControlSet is also stored under the HKEY_CURRENT_CONFIG root key. The Services subkey contains a list of drivers, file systems, and service programs that run in user mode, together with virtual hardware keys. The data contained in this key define the drivers to be loaded and specify their loading order. The data also define the methods used by the services to call each other. Multiple control sets are stored as subkeys under the HKEY_LOCAL_MACHINE\System registry keys under the names from ControlSet00l to ControlSet003. There can be as many as four control sets, but normally there are only two. This mechanism is similar to the one used to create the Config.sys backup copies for MS-DOS computers. Normally, there's one copy of Config.sys used to start the system, and the backup copy. In our case, however, the whole job of creating and maintaining the backup copies is performed automatically by the system. The Select subkey, shown in Fig. 7.14, contains four parameters, which describe the control set usage: The Default setting identifies the number of the control set (for example, 001=ControlSet001) that the system should use next time it starts up. This may happen when a system error prevents the system from booting or when you manually select the LastKnownGood option. The Current setting specifies the ordinal number of the control set that's actually been used to start the computer. The LastKnownGood setting specifies the ordinal number of the control set that was used the last time you successfully started up the system. The Failed setting specifies the control set that was replaced by the LastKnownGood control set (if it was used to start up the system). You can also examine this control set to identify the source of the problem, which you have to do in order to replace the current control set with the last known good one.