Xem mẫu

  1. Figure 7.14: The contents of the HKEY_LOCAL_MACHINE\SYSTEM\Select registry key The CurrentControlSet key is actually a symbolic link to the control set specified by the Current setting under HKEY_LOCAL_MACHINE\SYSTEM\Select. This is necessary so that constant paths can be used to refer to subkeys in the currently used control set, even though its name may change. Any time you start the system, the control set used to start up the system is stored under HKEY_LOCAL_MACHINE\System\Clone. If the system started successfully, this control set is considered "good", and the system discards the existing LastKnownGood control set. Actually, the system replaces the existing LastKnownGood control set with a copy of the Clone key. The system administrator can change this requirement at the startup process. Normally, startup is considered successful if no severe errors occurred and at least one user was able to log on to the system. The LastKnownGood configuration is used when you select the LastKnownGood option during startup, or if the startup process fails (in this case, the control set won't be considered "good"). If this happens, the system creates a new control set by copying the LastKnownGood control set. The values under HKEY_LOCAL_MACHINE\System\Select will change as follows: The control set identified as Default will became the Failed control set. The control set that was identified as LastKnownGood will become the Default control set. User profile data are stored under other registry keys, and these modifications won't be reflected in user profiles. Tip If you need to identify the control set used to start up your system, view the Select subkey. Using administrative utilities and Control Panel applets is the easiest method of modifying the data stored under the keys previously discussed.
  2. It's the CurrentControlSet subkey that you need to edit when modifying the configuration settings using one of the registry editors. Control Subkeys for Controls Sets Each control set contains a Control subkey. This subkey stores the startup parameters, including information on the subsystems to be loaded, environment variables, and the size and location of the paging file. The most important subkeys located under the Control key present in the control set are listed in Table 7.2. Table 7.2: Typical subkeys of the Control Key for All Control Sets Subkey Description BackupRestore This key contains nested keys that specify parameters for the Ntbackup program, including subkeys such as FilesNotToBackup and KeysNotToRestore (Fig. 7.15), which contain exclusion lists for files and registry keys not to be involved into backup or restore processes. The contents of the BackupRestore subkey can be used for customizing the built-in Microsoft Backup utility. Also notice the AsrKeysNotToRestore nested key, which is new in Windows XP and Windows Server 2003. This key relates to the Automated System Recovery process, which in newer releases has replaced the Emergency Repair Disk functionality included with Windows NT and Windows 2000. By default, it contains a single value entry named Plug ' Play (data type REG_MULTI_SZ, value CurrentControlSet\Control\CriticalDeviceDatabase\). This information will not be restored during the ASR process, which is not surprising, since such information must be re-created by the Setup program when it inspects the hardware configuration of your system. BootVerificationProgra This value can be used to specify a non-standard mechanism of m declaring the system startup as successful ("good"). If an additional verification mechanism hasn't been specified, this subkey won't contain any settings. ComputerName Default computer names and active computer names are stored under ComputerName and ActiveComputerName subkeys. To set the computer name, use the Network option in the Control Panel (Windows NT 4.0), the Network Identification tab in the System Properties window (Windows 2000) or the Computer
  3. Table 7.2: Typical subkeys of the Control Key for All Control Sets Subkey Description Name tab of the System Properties window (Windows XP and Windows Server 2003). CrashControl This key contains value entries that manage system behavior in case of a system crash, including options for creating a memory dump file. Notice the MinidumpDir string value, which is new to Windows XP and Windows Server 2003. As its name implies, this setting specifies the path to the directory where the small dumps, mainly used by the Error Reporting service, are stored. You can specify these settings in the Startup and Recovery window. GroupOrderList Specifies the order in which the system should load the services for all groups that have one. This option is used in combination with the Tags option. The ServiceGroupOrder setting specifies the loading order for the groups. ServiceGroupOrder Specifies the order in which to load various groups of services. The services loading order within a group is defined using the Tags and GroupOrderList settings. HiveList This setting specifies the location of the registry hive files (the contents of this key are shown in Fig. 7.16). The value is maintained by the system because the settings under this key show the exact location of the registry hive files (if these files can't be loaded, the startup process will fail). Pay attention to the format used to represent the names of these settings (Fig. 7.16). Note that they are represented as follows: \REGISTRY\MACHINE\, where the is the name of the appropriate registry hive. Also note the following scheme: \Device\HarddiskVolumeN\%SystemRoot%\System32\Config\, which is adopted because when an appropriate registry file needs to be loaded, the system has not yet created drive mappings for logical disks. KeyboardLayout DLL for the keyboard layout, the default language used as a default, plus a subkey named DosKeybCodes, which lists all other available keyboard layouts. LSA The authentication packages for the Local Security Authority (LSA). This value is maintained by the system. If you make an error editing this value, it may prevent everyone from logging in to the local system.
  4. Table 7.2: Typical subkeys of the Control Key for All Control Sets Subkey Description NetworkProvider This key can contain subkeys that specify network providers and the order in which to load them. You can manage the settings for network providers using the Network option in the Control Panel (Windows NT 4.0), the Network and Dial-up Connections option (Windows 2000) or Network Connections option (Windows XP and Windows Server 2003). NLS This subkey contains information on national language support (NLS). You can manage the national language support using the following Control Panel applets: Regional Settings (Windows NT 4.0), Regional Options (Windows 2000) or Regional and Language Options (Windows XP and Windows Server 2003). Print This subkey contains information on the currently installed printers and printing environment. It has the following important subkeys: Environments-this subkey contains other subkeys that define drivers and print processors for various system environments. Monitors-this subkey contains other subkeys that store data for specific network printing monitors. Printers-this subkey contains other subkeys that describe the settings for each installed printer. Providers-this key can contain subkeys describing print services' DLLs. To modify the printer settings, click the Start button, then select Settings | Printers. PriorityControl This subkey specifies the priority separation in Win32. You should only set this value using the System option in Control Panel. ProductOptions This subkey defines the software product type (Windows NT, for example). These values are maintained by the system. Notice one especially interesting fact: the ProductType value in Windows 2000 registry is set to "WinNT". SessionManager This subkey specifies global variables used by Session Manager. This key can, in turn, contain the following subkeys: DOS Devices-the subkey that identifies various DOS devices
  5. Table 7.2: Typical subkeys of the Control Key for All Control Sets Subkey Description such as AUX, MAILSLOT, NUL, PIPE, PRN, and UNC. Environment-this key identifies environment variables such as ComSpec, Path, Os2LibPath, and WinDir. These variables are set using the System option in Control Panel (this is the same for both Windows NT 4.0 and Windows 2000 and its successors). FileRenameOperations-this key is used during the startup process. It allows you to rename certain files in order to replace them. These values should be maintained only by the operating system. KnownDLLs-this key defines the directories and filenames for Session Manager DLLs. Again, all these values are maintained by the operating system. MemoryManagement-this key defines the paging options. Normally, you specify the paging file parameters using the System applet in the Control Panel. Notice that in Windows NT/2000 this key contains the RegistrySizeLimit setting mentioned in Chapter 1. Also notice that in Windows XP and Windows Server 2003 this setting has become obsolete. SubSystems-this key defines information intended for Windows NT/2000, Windows XP, and Windows Server 2003 subsystems. The values under this key are maintained by the system. Setup This key specifies hardware setup options. Once again, all the values under this key are maintained by the operating system. If you need to modify these settings, the easiest way is to start the Windows Setup program. TimeZoneInformation This key contains the values that define time zone information. Normally, you set these values using the Date/Time option in the Control Panel. VirtualDeviceDrivers This subkey contains virtual device drivers. These values must be maintained by the system. Windows This subkey specifies the paths to the Windows directory and system directory. WOW The settings stored under this key define options for 16-bit Windows applications. Once again, these settings should be
  6. Table 7.2: Typical subkeys of the Control Key for All Control Sets Subkey Description maintained by the system. Figure 7.15: The contents of the BackupRestore nested key Figure 7.16: The hivelist subkey The Enum Subkey for All Control Sets The Enum subkey contains configuration data for all hardware devices, independent of the drivers these devices use. This subkey was first introduced in Windows NT 4.0. It was added to enable Windows NT to access devices and their drivers and manage them using methods similar to those used in Windows 95. (Notice that these methods are similar, but not the same, because Windows NT architecture is different from that of Windows 95.) These changes were intended to lay the groundwork for providing support for new Plug and Play devices in future versions of Windows NT. As we saw in Chapter 5, full- featured PnP support was first implemented in Windows 2000, and further enhanced in Windows XP and Windows Server 2003. Note Don't use registry editors to modify this key. If you make an error, neither Windows NT/2000 nor Windows XP/Windows Server 2003 will be able to detect hardware
  7. devices. Normally, the Enum key contains configuration data for hardware devices. The subkeys under the Enum key form a hierarchical structure known as the hardware device tree. The hardware tree starts at the tree root and ends at the lowest branch containing configuration data for a specific instance of the device (for example, the keyboard on the local computer). The Enum key itself can be considered to be a container that isn't associated with any value. This key contains at least two subkeys: the Htree subkey, which represents the hardware tree; and one or more enumerators, which are used by Windows to get information about specific devices. The Htree\Root\0 key is a reserved registry space representing the root of the hardware tree (this is the same for Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003). Since Windows 2000 and newer releases implement full-featured Plug and Play support, the contents of the Enum key have become more complicated than those found in Windows NT 4.0. The screenshot shown in Fig. 7.17 shows the Enum key structure for Windows Server 2003. Figure 7.17: The HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum key structure The remaining subkeys directly under the Enum key represent enumerators and contain subkeys for devices on the same enumerator. According to Plug and Play requirements, each enumerator has its respective device bus (for example, PCI or ISAPNP). The default enumerator (Root) is used for non-PnP (legacy) devices. Each subkey of the enumerator contains multiple subkeys that represent various device types and models. The subkeys representing device types, in turn, contain their own subkeys that identify specific instances of the devices of this type. The name of each device type subkey identifies the device as a legacy device or as a Plug and Play device.
  8. For most non-Plug and Play devices, Windows NT-based OS creates a device-type ID in the LEGACY_ format. This subkey contains data for all the devices managed by this driver. The subkeys below the device type keys are keys representing specific device instances. They contain the setting, which specifies device configuration. The settings and subkeys directly below the device instance keys may be different, and vary depending on the devices and their drivers. The Services Subkey for All Control Sets Each control set contains a Services subkey that lists the device drivers, file system drivers, and Win32 service drivers. All the drivers listed under this key may be loaded by the operating system boot loader (Ntldr), I/O Manager, or Service Control Manager. As I already mentioned earlier in this chapter while discussing the HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP registry key, all the subkeys under this key contain the settings that reference the entries under the Services key within the control set. For example, in Windows NT/2000, the following entry may be present in the DeviceMap\PointerPort subkey for the parallel port mouse: \Device\PointerPort0: \REGISTRY\Machine\System\ControlSet001\Services\Sermouse The Services key must contain the key corresponding to this link, which is named Sermouse. This subkey identifies the mouse driver settings. This mechanism is called device mapping, which explains why the registry key is called DEVICEMAP. Note In Windows XP and Windows Server 2003, to facilitate device installation, devices are set up and configured using device setup class grouping. The device setup class defines the class installer and class co-installer components that are involved in installing the device. Therefore, the following entry for the parallel port mouse under HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\PointerClass will result (Fig. 7.18). Notice that the key name is PointerClass and not PointerPort, as it was in Windows NT/2000:
  9. Figure 7.18: An example of the contents of the HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\PointerClass registry key in Windows XP \Device\PointerClass0: \REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\Mouclass Like in Windows NT/2000, the Services key contains the key corresponding to this link, which is named Mouclass. This subkey identifies the mouse driver settings (Fig. 7.19). At the beginning of the chapter, we discussed this mechanism in the example on video drivers. Figure 7.19: The Services key contains the key corresponding to the link provided under DEVICEMAP registry key Microsoft defines setup classes for most devices. IHVs and OEMs can define new device setup classes, but only if none of the existing classes apply. For example, a camera vendor doesn't need to define a new setup class because cameras fall under the Image setup class. Similarly, uninterruptible power supply (UPS) devices fall under the Battery class. The class installer defines the class of the component to be installed by the ClassGuid value. There is a GUID associated with each device setup class. The ClassGuid value is the Globally Unique Identifier (GUID) for the class. You can generate GUID values using the Uuidgen.exe utility. More detailed information about this utility is provided in Platform SDK supplementary documents.
  10. The device setup class GUID defines the … \CurrentControlSet\Control\Class\ClassGUID registry key under which to create a new subkey for any particular device of a standard setup class. Each subkey under the Services key may contain several optional settings. For example, the content of the Alerter key specifies the Alerter service parameters. Settings such as ErrorControl, Group, DependOnGroup, DependOnService, ImagePath, ObjectName, Start, Tag, and Type manage service behavior. The loading order for services and drivers is specified by the \Control\ServiceGroupOrder key under the control set key. The Hardware Profiles Key for All Control Sets The Hardware Profiles subkey is present in any control set. These subkeys contain configuration data for all hardware profiles created in Windows NT/2000, Windows XP, or Windows Server 2003. This key was first introduced in Windows NT 4.0. As you already know, the hardware profile is a set of modifications introduced to facilitate standard device and service configuration (including Win32 services and drivers) loaded at system startup. Windows NT-based operating system creates a default hardware profile based on the original configuration detected during OS installation. You can create multiple hardware profiles and select existing profiles at boot time. Fig. 7.20 shows a typical structure of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles registry key. Figure 7.20: The contents of a typical HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles key
  11. Each subkey under the Hardware Profiles key contains configuration data for its respective hardware profile. If the system has more than one hardware profile, it identifies the hardware profile as current when you select it at boot time. The HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles\Current registry key represents a symbolic link to one of the keys named 0000, 0001, … The HKEY_CURRENT_CONFIG tree is an alias that references the Hardware Profiles\Current key under the CurrentControlSet. The contents of the Current key also appear under the HKEY_CURRENT_CONFIG tree. Tip To define which of the 0000, 0001, …, 000n keys under the Hardware Profiles keys is selected as the current one, view the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\IDConfigDB key. This key contains the CurrentConfig setting (Fig. 7.21), whose value specifies the number corresponding to the key that contains the current hardware profile. Figure 7.21: The contents of the IDConfigDB subkey The settings contained within each hardware profile subkey represent individual modifications of the standard configuration of the system services and device drivers. These modifications correspond to the goals of each hardware profile. Notice that these keys only store data different from the standard configuration, which is defined by the data stored under the Software and System subkeys under HKEY_LOCAL_MACHINE. Consequently, the hardware profile structure is modeled based on the structure of the HKEY_LOCAL_MACHINE registry key. Strictly speaking, it can be considered to be a limited, or compressed, version of this key. If the hardware profile contains a changed version of a value entry under the Software or System keys of HKEY_LOCAL_MACHINE, then the original value isn't changed. Rather, the changed version of this value is stored within a similar key of the Hardware Profiles\ subtree. For example, let's look at a situation when you create a new hardware profile that excludes the Iomega Parallel Port Legacy Filter Driver (ppa3). The HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\Root\LEGACY_PPA3
  12. key won't be changed in Windows NT 4.0, Windows 2000, Windows XP, or Windows Server 2003. On the contrary, this modification will be stored under the following key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Hardware Profiles \\System\CurrentControlSet\Enum\Root\LEGACY_PPA3. The Setup Subkey The Setup subkey under the HKEY_LOCAL_MACHINE\System tree is intended for internal use by the Setup program. You need not (and should not) change the value entries under this key, because they are to be maintained by the operating system. The Disk Subkey The HKEY_LOCAL_MACHINE\SYSTEM\Disk subkey has undergone significant changes since its appearance in Windows NT 4.0. In the Windows NT 4.0 registry, this key contained all the information needed to manage the volumes. This key is created by the Disk Administrator built-in Windows NT utility and contains the Information setting (data type is REG_BINARY). This setting contains all configuration information, including the data on the hard disk partitions that were recognized by Windows, drive mappings, and the data concerning fault-tolerant disk configurations (mirror sets, stripe sets with or without parity), if you've created the fault-tolerant disk configurations. Detailed information concerning fault-tolerant disk configurations is provided in the documentation supplied with the Windows NT 4.0 Workstation Resource Kit software. The HKEY_LOCAL_MACHINE\System\Disk key is created in the Windows NT 4.0 registry when you start the Disk Administrator utility for the first time. This utility creates both the key and the Information binary setting, which stores all the data on the hard disks present in the system. As you create or delete hard disk partitions using the Disk Administrator utility, or configure fault-tolerant volumes, the program stores all configuration changes in the Information setting. If you explicitly establish drive mapping for the CD-ROM drive (for example, you need to map this drive as "H:"), the Disk key will contain another setting named \device\CdRom0. This string setting will have a value that corresponds to the drive mapping that you've specified. Besides the Disk Administrator utility, there are other drivers and subsystems that access the Disk key information. For example, this information is available to the fault-tolerant file system driver (Ftdisk.sys) and to the Win32 subsystem. The Ftdisk.sys driver identifies whether or not there are fault tolerant disk configurations in the system, such as mirror or stripe sets. The driver does this by reading the Information setting. The Win32 subsystem needs the Information setting data for establishing drive mappings.
  13. Note The Information setting is a variable-length setting, because the number of logical disks and fault tolerant volumes in each individual Windows NT 4.0 system are also variable. With the release of Windows 2000, the disk management subsystem has undergone significant changes (for example, a new type of volume was introduced-dynamic volume). The HKEY_LOCAL_MACHINE\SYSTEM\Disk\Information setting is present in the registry (in order to provide backward compatibility), but it no longer stores information on fault-tolerant volumes. Windows 2000, Windows XP, and Windows Server 2003 store the information on fault- tolerant volumes directly on the hard disk. There's a noticeable difference, though. The Ftdisk.sys driver in Windows 2000/XP and Windows Server 2003 manages all disk partitions, including the fault-tolerant volumes and all other partitions that exist on the hard disks. So, even if you don't configure the fault-tolerant volumes on your computer running Windows 2000, Windows XP, or any product of the Windows Server 2003 family, Ftdisk.sys loads anyway and detects all requests to the hard disks.