Hklm software microsoft windows current version windows

HKEY_LOCAL_MACHINE

Это поддерево содержит информацию о компьютере, его оборудовании, установленных
драйверах устройств и опциях конфигурации (для настроек безопасности и
настроек ПО), которые влияют на всех пользователей данного компьютера. Оно
содержит пять разделов: Hardware, SAM, Security, Software и System. Все эти разделы,
кроме Hardware, присутствуют на диске в виде файлов ульев.

HKLM\Hardware

Ntdetect.com («распознаватель оборудования» Windows Server 2003) создает весь этот
раздел во время загрузки. Эта информация содержится в RAM-памяти (вы можете
интерпретировать этот раздел как содержащийся в памяти файл улья), что позволяет
Windows находить информацию о данной машине во время загрузки операционной
системы. В иерархической структуре подразделов содержится информация обо
всех компонентах оборудования компьютера.

HKLM\SAM

Это данные, используемые для диспетчера учетных записей Security Accounts Manager
(SAM), недоступны через редакторы реестра. Улей SAM, находящийся по умолчанию
в %SystemRoot%\System32\Config является хранилищем таких данных для
пользователей и групп. В данные SAM включены все локальные пользователи и группы,
в том числе полномочия доступа пользователей к папкам, файлам и периферийному
оборудованию. Большое количество данных о группах и пользователях
домена, которые содержались в улье SAM реестра Windows NT 4, содержатся теперь
в Active Directory системы Windows Server 2003 (и Windows 2000).

HKLM\Security

Аналогично подразделу SAM данные подраздела Security содержатся в соответствующем
улье. Пользователи не могут просматривать или изменять эти данные интерактивно
в редакторе реестра. Улей Security находится в том же месте на жестком
диске, что и улей SAM.

Содержимое улья Security относится к средствам безопасности, и его данные
зависят от того, что вы еще работаете (или уже не работаете) в смешанном режиме.
Если серверы Windows NT все еще участвуют в аутентификации, то улей Security
содержит настройки конфигурации для пользовательских и групповых политик NT
4 в дополнение к политикам безопасности Windows Server 2003/Windows 2000.

HKLM\Software

Это обширный раздел, содержащий несколько уровней подразделов в виде иерархической
структуры. Компании-разработчики ПО обычно добавляют свой раздел в
это поддерево (и обычно добавляют тот же раздел в HKEY_CURRENT_USER\Software )
с подразделами для имени, версии и других компонентов продукта.

Операционная система хранит здесь настройки компьютера, включая настройки,
которые определяются групповыми политиками.

HKLM\System

Это огромный раздел! Многие из его подразделов и элементов данных управляют
загрузкой операционной системы (см.
«Загрузка»
); другие подразделы и элементы данных
управляют почти всем, что делает операционная система (особенно службы ядра).
Это определяющий раздел для настроек конфигурации компьютера, но подробное
описание этого раздела выходит за рамки изложения данного курса.

HKEY_USERS

Это поддерево содержит подразделы для профиля Default User и всех известных
профилей пользователей для данного компьютера. Каждый подраздел с профилем
отдельного пользователя идентифицируется идентификатором безопасности
(Security ID, SID) и раскрывается в виде полного набора подразделов с настройками
(для раздела HKEY_CURRENT_USER, когда данный пользователь выполняет
вход).

HKEY_CURRENT_CONFIG

Это поддерево содержит информацию о профиле оборудования, который используется
данным компьютером при загрузке. Это алиас для HKEY_LOCAL_MACHINE\System\CurrentControlSet\Hardware Profile\Current.

Regedit.exe

Regedit.exe – это единственный редактор реестра в Windows Server 2003; regedt32 уже
не используется. (Если открыть Start\Run и ввести regedt32, то откроется Regedit.exe.)
Большинство из тех, кто часто работает с реестром, всегда предпочитали интерфейс
Regedit.exe и использовали regedt32 только для задания настроек безопасности. Теперь
настройки безопасности доступны и в Regedit.exe, то есть фактически мы не
потеряли regedt32.

Как заставить Regedit не отображать последний из использовавшихся разделов

Одной из неприятных (для меня) особенностей Regedit в Windows Server 2003 (и в
Windows 2000) является то, что при открытии этого редактора появляется последний
из использовавшихся вами разделов. Иногда это раздел, находящийся далеко
внизу дерева, и требуется много работы, чтобы выполнить прокрутку, закрытие разделов
и прочие операции в левой панели для перехода к разделу, который вы хотите
использовать на этот раз. Чтобы изменить это поведение, вы должны выполнить
две задачи.

• Удалить информацию о последнем из использовавшихся вами разделов.
• Указать системе, чтобы она не записывала эту информацию при вашем следующем доступе к какому-либо разделу.

Чтобы выполнить эти задачи, выполните следующие шаги.

1. Перейдите в HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ Applets\Regedit.
2. Дважды щелкните в правой панели на элементе данных LastKey и удалите значение, создав пустую строку.
3. Щелкните на кнопке OK, чтобы закрыть String Editor.
4. Снова щелкните правой кнопкой на разделе Regedit в левой панели и выберите в контекстном меню пункт Permissions (Полномочия).
5. Щелкните на кнопке Advanced, чтобы открыть диалоговое окно Advanced Security Settings (Дополнительные настройки безопасности).
6. Выберите свое пользовательское имя и щелкните на кнопке Edit, чтобы открыть диалоговое окно Permission Entry (Ввод полномочий).
7. Выберите опцию Deny (Запретить) для полномочий Set Value (Задание значения).
8. Выберите этот новый элемент Deny<ваша-пользовательская-учетная-запись> и щелкните на кнопке Edit. Затем выберите в раскрывающемся списке Apply Only (Применять только) вариант This Key Only (Только этот раздел). (Это ограничит запрет полномочий Set Value только подразделом Regedit, и не будет влиять на подраздел Favorites.)
9. Щелкните на кнопке OK три раза, чтобы закрыть диалоговое окно Permissions (после второго щелчка на кнопке OK вам нужно будет подтвердить тот факт, что вы внесли эти изменения).

Раздел Regedit не существует, если вы еще не запускали Regedit на данном компьютере.
Если этого раздела нет, не добавляйте его в реестр вручную. Вместо этого
откройте и закройте Regedit, чтобы создать этот раздел, и затем снова откройте
Regedit, чтобы выполнить указанные шаги.

Если вы не хотите выполнять все эти шаги, то можете закрывать все разделы
вручную, удерживая клавишу Shift и непрерывно нажимая клавишу «левая стрелка»,
пока не произойдет сжатие всей иерархической структуры. Лично я считаю это
мучительным занятием.

Дистанционный доступ к реестрам

Вы можете использовать Regedit для поиска и управления в реестре другого компьютера
в вашей сети. Выберите File\Connect Network Registry (Подсоединиться к реестру
в сети), чтобы открыть диалоговое окно Select Computer (Выбор компьютера).
Введите имя компьютера, к которому вы хотите подсоединиться, или щелкните на
кнопке Advanced для поиска этого компьютера.

Картинка с сайта: intuit.ru

Поддерево удаленного реестра выводится вслед за поддеревьями вашего локального
реестра. Отметим, что реально только два поддерева выводятся для удаленного
компьютера (напомним, что все остальные поддеревья образуются из этих двух
поддеревьев).

Картинка с сайта: intuit.ru

Вы можете одновременно подсоединяться к нескольким удаленным реестрам, и
каждый набор поддеревьев идентифицируется именем компьютера.

Картинка с сайта: intuit.ru

Чтобы отсоединиться от реестра удаленного компьютера, выберите
File\Disconnect Network Registry (Отсоединить реестр в сети), щелкните на имени
соответствующего компьютера и щелкните на кнопке OK.

Картинка с сайта: intuit.ru

Примечание. Если вы забыли отсоединиться, то при закрытии Regedit произойдет
автоматическое отсоединение всех удаленных реестров.

Поиск в реестре

Regedit содержит эффективное средство поиска данных в реестре. Чаще всего я открываю
реестр для поиска данных после установки приложения. Кроме того, иногда
поиск в реестре – это единственный способ найти причину сообщения об ошибке,
где говорится об отсутствии какого-либо исполняемого файла во время загрузки.

Поиск в реестре выполняется «сверху вниз», а это означает, что поиск начинается
с точки, где вы находились перед запуском поиска. Если начать сверху (My Computer),
то поиск охватывает все поддеревья. Если у вас нет причины выполнять поиск информации
о классах, то лучше всего начинать с HKEY_CURRENT_USER или HKEY_LOCAL_MACHINE. Если у вас есть основания быть уверенным, что искомые
данные находятся в какой-либо конкретной части реестра, раскройте соответствующее
поддерево и начните поиск с соответствующего раздела или подраздела.

Вы можете открыть диалоговое окно Regedit Find, используя любое из следующих
действий.

• Выбрать Edit\Find.
• Нажать клавишу F3.
• Нажать клавиши CTRL-F.

После начала поиска клавиша F3 используется уже для другой цели – поиск следующего
экземпляра искомой строки.

В диалоговом окне Find введите строку поиска и, если это имеет смысл, введите
конкретный тип данных. Затем щелкните на кнопке Find Next (Найти далее).

Картинка с сайта: intuit.ru

Если вы нашли нужную строку и этот экземпляр вам не подходит, щелкните на
кнопке F3, чтобы искать следующий экземпляр.

Примечание. Часто бывает трудно определить, чем является искомая строка:
разделом, элементом данных или значением. Приложения могут добавлять подразделы с
именами, которые, казалось бы, должны быть именами элементов данных.

Создание списка Favorites

Если имеются разделы реестра, которые вы часто посещаете для просмотра данных
или работы с ними, то можете сохранить эти разделы в списке Favorites (Избранное).
Чтобы добавить какой-либо раздел в свой список, выделите этот раздел и выберите
Favorites\Add to Favorites. Появится диалоговое окно Add to Favorites, чтобы
позволяет вам присвоить имя данному элементу. По умолчанию выводится имя раздела,
но вы можете уточнять название. Например, я добавил в свой список Favorites
подраздел HKCU\Software\Microsoft\Windows\CurrentVersion\Policies. В диалоговом
окне было представлено имя Policies, но поскольку имеется много подразделов с
этим именем, я изменил название, чтобы стало ясно, что это раздел, где содержатся
пользовательские политики.

Ваш список избранных разделов появится в меню Favorites. Чтобы сразу перейти
в какой-либо подраздел, щелкните на его имени в этом списке.

Чтобы удалить какую-либо запись из вашего списка Favorites, выберите
Favorites\Remove Favorites. В диалоговом окне Remove Favorites выберите запись,
которую хотите удалить, и щелкните на кнопке OK.

В отличие от списка Favorites в Internet Explorer вы не можете переименовать
запись. Вместо этого приходится удалить запись и добавить ее снова. Наиболее быстрый
способ – это щелкнуть на записи, чтобы перейти в соответствующий раздел,
удалить запись и затем выбрать Add to Favorites (вы находитесь в нужном разделе),
чтобы снова создать запись (введя на этот раз более осмысленное описательное имя).

The HKEY_LOCAL_MACHINE Key

HKEY_LOCAL_MACHINE is one of the most important and most interesting root keys of the registry. It contains configuration data for local computer. Information stored in this registry key is used by applications and device drivers and by the operating system itself for obtaining information on the local computer’s configuration. Moreover, the information doesn’t depend on the user who’s logged in to the system.

The HKEY_LOCAL_MACHINE root key contains five subkeys, briefly described in Table 7.1. The rest of this section describes the subkeys in greater detail.

Table 7.1: Subkeys Contained within the HKEY_LOCAL_MACHINE Root Key

If the HKEY_CURRENT_USER registry key contains data similar to that contained under HKEY_LOCAL_MACHINE, then by default the HKEY_CURRENT_USER data takes priority.

However, the settings under this key may also extend the data under HKEY_LOCAL_MACHINE rather than replace them. Furthermore, there are certain settings (for example, those that manage the device driver loading order) that have no meaning outside the HKEY_LOCAL_MACHINE root key.

The HKEY_LOCAL_MACHINE\HARDWARE Key

The HKEY_LOCAL_MACHINE\HARDWARE registry key contains hardware data recreated during each system startup. This data includes information about the devices on the motherboard and the data on the IRQs used by individual device drivers.

The HARDWARE key contains important data sets subdivided between the following three subkeys: DESCRIPTION, DEVICEMAP, and RESOURCEMAP.

All the information contained under HKEY_LOCAL_MACHINE\HARDWARE is volatile. This means that the settings are computed and recreated each time the system starts up, and are lost when you shut the system down. All drivers and applications use this subtree for obtaining information on system components and for storing the data directly under the DEVICEMAP subkey and indirectly under the RESOURCEMAP subkey (Fig. 7.1).

Figure 7.1: The HKEY_LOCAL_MACHINE\HARDWARE registry key

Don’t try to edit the data under HKEY_LOCAL_MACHINE\HARDWARE directly. This information is usually stored in binary format and is difficult to understand if you can’t interpret binary data.

Figure 7.2: The System Information utility allows you to view hardware information in user-friendly format

The DESCRIPTION Subkey

The DESCRIPTION subkey under HKEY_LOCAL_MACHINE\HARDWARE displays information from the hardware database. For x86 computers, this information contains data on the devices detected by Ntdetect.com and Ntoskrnl.exe.

Ntdetect.com is the standard DOS-style program that uses BIOS calls for selecting hardware information and configuring hardware devices. This includes date and time information stored in the CMOS chip; bus types (for example, ISA, PCI, EISA) and identifiers of the devices on these buses; data on the number, type, and capacity of the hard drives installed in the system; and the number and types of parallel ports. Based on this information, the system creates internal data structures that Ntoskrnl.exe stores under HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION during system startup.

A specific feature of the Ntdetect.com version included with Windows 2000, Windows XP, and Windows Server 2003 is that PnP detection functions are delegated to PnP drivers. In contrast, the Windows NT 4.0 version of Ntdetect.com detects all installed hardware (due to limited PnP support in Windows NT 4.0).

Ntdetect.com detects the following hardware:

• Type of bus\adapter

• Keyboard

• SCSI adapters

• COM-ports

• Machine ID

• Video adapter

• Arithmetic coprocessor

• Mouse

• Floppy drives

• Parallel ports

There are more subkeys, each of them corresponding to a certain bus controller type. These subkeys are located under HKEY_LOCAL_MACHINE\Hardware\Description\System\MultifunctionAdapter. Each of these keys describes a specific controller class (including hard disk controllers, display controllers, parallel port controllers, and SCSI controllers). The path to the subkey describes the component type. All physical devices are numbered, beginning from 0.

Each detected hardware component has Component Information and Configuration Data settings, which contain binary data on the version of a specific component and its configuration (Fig. 7.3). The Identifier setting contains the component name (if specified).

Figure 7.3: The HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\MultifunctionAdapter registry key

The DEVICEMAP Subkey

The HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP registry key contains a set of sub-keys equipped with one or more settings that specify the path to the drivers required by each device. Let’s consider using this information for searching for device drivers. For example, how does the registry store information on the video drivers? Fig. 7.4 shows an example illustrating the contents of the VIDEO subkey under the DEVICEMAP key (the information you’ll see when you open the registry key will differ from what’s shown in this figure). However, the information will show you what you’ll see in general.

The HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\VIDEO registry key contains settings that are actually links to currently active devices. These registry items use an ordinal-naming scheme (for example, in Fig. 7.4 it’s \Device\VideoN, where N is an ordinal number (0, 1, 2…)). The values of each of these registry settings are REG_SZ strings that reference particular device drivers.

Figure 7.4: The HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\VIDEO registry key

All Windows NT-based operating systems, including Windows 2000, Windows XP, and Windows Server 2003, are object-oriented, which means that they manipulate several object types, including devices, ports, events, directories, and symbolic links. Registry keys are objects of special types. The registry root key is the object of the Key type named REGISTRY. In the DDK (Device Driver Kit) documentation, the names of all the registry keys begin with the \REGISTRY string (for example, \REGISTRY\Machine\CurrentControlSet\Services). Thus, the HKEY_LOCAL_MACHINE handle is the key named \REGISTRY\Machine, and the HKEY_USERS handle is the key named \REGISTRY\User.

Now let’s expand the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\{56652C39-3E1C-4A83-AD68-1CF58F0EDEE9}\0000 registry key (Fig. 7.5).

Figure 7.5: The contents of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\{56652C39-3E1C-4A83-AD68-1CF58F0EDEE9}\0000 registry key

This key contains quite a lot of entries, mainly in binary format, among which is the Device Description value (data type REG_SZ) that contains the device description (NVIDIA RIVA TNT, in our example). Besides, it also possesses another value, InstalledDisplayDrivers, which references the driver for this device (nv4_disp in our example). The nested Video key contains the Service value entry referencing the nv service (Fig. 7.6). Information on this service can be found in the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services registry key (Fig. 7.7). It must exist for the device to function properly, and you’ll certainly find it.

Figure 7.6: The contents of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\{56652C39-3E1C-4A83-AD68-1CF58F0EDEE9}\Video registry key

Figure 7.7: The contents of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\nv registry key

The key that you are locating contains standard settings that specify the start mode for the driver: Start, Tag, Type, ErrorControl, and Group. Depending on the driver type, its key may contain several other settings, such as the ImagePath setting that specifies an actual path to the directory where the driver resides (system32\DRIVERS\nv4_mini.sys, in our example).

In addition to the settings listed above, the video driver key under HKEY_LOCAL_MACHINE\SYSTEM\ControlSetnnn\Services contains several subkeys. One of the most important subkeys within this key is DeviceN-in our example, this is the Device0 subkey (Fig. 7.8).

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 

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 multiple <DeviceClass> subkeys, which are used to store information on specific device driver classes. Each of these keys contains one or more <DriverName> 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.

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

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 <Description> 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 <Filename-extension> 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.

• <Class-definition> 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.

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:

   HKEY_LOCAL_MACHINE\Software\Description\CompanyName\ProductName\Version.

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).

Figure 7.13: The HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion registry key

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\   Image File Execution Options\<ImageName>]   "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 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:

• 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.

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.

Using administrative utilities and Control Panel applets is the easiest method of modifying the data stored under the keys previously discussed.

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

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.

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.

For most non-Plug and Play devices, Windows NT-based OS creates a device-type ID in the LEGACY_<DriverName> 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.

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:

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.

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

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.

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\<Number> 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 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   \<Number>\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.

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.

From Wikipedia, the free encyclopedia

«WDK» redirects here. For the ISO 639 code wdk, see Yarli language.

Windows Driver Kit

The Windows Driver Kit (WDK) is a software toolset from Microsoft that enables the development of device drivers for the Microsoft Windows platform.^[2] It includes documentation, samples, build environments, and tools for driver developers.^[3] A complete toolset for driver development also need the following: a compiler Visual Studio, Windows SDK, and Windows HLK.

Previously, the WDK was known as Device Development Kit (DDK)^[4] for Windows 3.x and Windows 9x. It supported the development of VxD drivers. Later versions for Windows NT and Windows 98SE and ME were called Driver Development Kit (DDK)^[5] and supported Windows Driver Model (WDM) development. It got its current name when Microsoft released Windows Vista and added the following previously separated tools to the kit: Installable File System Kit (IFS Kit), Driver Test Manager (DTM), though DTM was later renamed and removed from WDK again.

The DDK for Windows 2000 and earlier versions did not include a compiler; instead one had to install Visual C++ separately to compile drivers. From the version for Windows XP the DDK and later the WDK include a command-line compiler to compile drivers. One of the reasons Microsoft gave for including a compiler was that the quality of drivers would improve if they were compiled with the same version of the compiler that was used to compile Windows itself while Visual C++ is targeted to application development and has a different product cycle with more frequent changes. The WDK 8.x and later series goes back to require installing a matched version of Visual Studio separately, but this time the integration is more complete in that you can edit, build and debug the driver from within Visual Studio directly.

Note: Windows NT DDK, Windows 98 DDK and Windows 2000 DDK are no longer made available by Microsoft because of Java-related settlements made by Microsoft with Sun Microsystems.^[6]

• Windows Driver Frameworks
• Windows Driver Model
• Windows Logo Kit