11.2 HKLM\HARDWARE

HKLM\HARDWARE is the odd man out in the Registry for two reasons. First of all, all its keys are volatile, meaning they're never stored on disk. This is because when Windows 2000 or NT 4.0 boots, they can interrogate the system to find out what hardware's present, but they need to keep track of that information before any device drivers have actually been loaded. Since there's no requirement that Registry hives actually be stored in a hive file^[2] (instead of in RAM), loading HARDWARE into RAM as a volatile hive makes it accessible to boot-time components and the driver loading phase. Because its contents are volatile, changes you make to this hive won't be stored on disk.

^[2] There may as well be such a rule, though; HARDWARE 's the only volatile hive.

The second odd thing about this subkey is that almost all its values are stored as REG_BINARY values. This makes it difficult to edit values in this tree. That's actually a good thing, because doing so can suddenly render your machine inoperable. Since the system creates this tree from scratch each time it boots, there won't be any permanent damage, but you should still treat this tree as read-only.

11.2.1 HARDWARE\DESCRIPTION

The DESCRIPTION subkey stores data to represent what actual physical hardware is present when the system first starts up. This list may have items on it that don't appear in the DEVICEMAP or RESOURCEMAP subkeys; for example, a SCSI adapter that fails to initialize will be in DESCRIPTION but may not appear in either of the others.

The data in DESCRIPTION comes from the hardware recognizer. On x86 machines, this task is handled by ntdetect.com. The recognizer gathers data about the configuration of the system's buses, serial, parallel, mouse, and keyboard ports, SCSI and video adapters, and floppy drives. Notice that network adapters, PCMCIA cards, and external devices like printers aren't included on this list; they're not automatically detected in Windows 2000 and NT 4.0.

Each bus controller (ISA, PCI, EISA, etc.) gets its own subkey under Multi-functionAdapter ; in turn, each of these keys has subkeys for each device found on that bus. For example, HARDWARE\DESCRIPTION\System\MultifunctionAdapter\3\DiskController\0 points to the first disk controller on my desktop machine's motherboard bus. If I had a secondary controller, it appears as DiskController\1.

Any device in the DESCRIPTION tree may optionally have values named ComponentInformation and ConfigurationData. These values, both of which are of type REG_BINARY, store information about the device; the exact contents vary by device type, and frankly I don't know the details.

11.2.2 HARDWARE\DEVICEMAP

DEVICEMAP links devices in the DESCRIPTION subtree with device drivers in HKLM\SYSTEM\ControlSetX\Services. Each device that requires a driver has an entry that points to a driver in one of the control sets. During the two driver start phases, the kernel can consult entries in DEVICEMAP to find the matching entry in the Services subkey; that data specifies what driver should be loaded, what phase it should be loaded in, and what configuration data it requires. (See Section 11.4.2 later in this chapter for details on the Services subkey.)

11.2.3 HARDWARE\RESOURCEMAP

DEVICEMAP ties hardware entries to device drivers; RESOURCEMAP ties those same device drivers to physical machine resources such as DMA address ranges and IRQs. Since there is a finite number of these hardware resources, and since conflicts between multiple devices can render them all inoperable, this subkey is an important part of the Windows 2000/NT load phase.

Each class of device has its own subkey under RESOURCEMAP ; for example, RESOURCEMAP\ScsiAdapter is the device class key for (you guessed it) SCSI adapters. Every device in that class gets its own subkey under its class key. That means that a machine with two SCSI adapters has two entries, the names of which correspond to the device driver names in the Services subkey.

The contents of RESOURCEMAP come from the device drivers themselves. When a device driver starts, it claims whatever resources it needs for its hardware device and updates its entry in RESOURCEMAP to indicate what it used.