Windows Registry

The Windows Registry is a hierarchical database that stores low-level settings for the Microsoft Windows operating system and for applications that opt to use the registry. The kernel, device drivers, services, Security Accounts Manager, and user interfaces can all use the registry. The registry also allows access to counters for profiling system performance.
In other words, the registry or Windows Registry contains information, settings, options, and other values for programs and hardware installed on all versions of Microsoft Windows operating systems. For example, when a program is installed, a new subkey containing settings such as a program's location, its version, and how to start the program, are all added to the Windows Registry.
When introduced with Windows 3.1, the Windows Registry primarily stored configuration information for COM-based components. Windows 95 and Windows NT extended its use to rationalize and centralize the information in the profusion of INI files, which held the configurations for individual programs, and were stored at various locations. It is not a requirement for Windows applications to use the Windows Registry. For example,.NET Framework applications use XML files for configuration, while portable applications usually keep their configuration files with their executables.

Rationale

Prior to the Windows Registry,.INI files stored each program's settings as a text file or binary file, often located in a shared location that did not provide user-specific settings in a multi-user scenario. By contrast, the Windows Registry stores all application settings in one logical repository and in a standardized form. According to Microsoft, this offers several advantages over.INI files. Since file parsing is done much more efficiently with a binary format, it may be read from or written to more quickly than a text INI file. Furthermore, strongly typed data can be stored in the registry, as opposed to the text information stored in.INI files. This is a benefit when editing keys manually using regedit.exe, the built-in Windows Registry Editor. Because user-based registry settings are loaded from a user-specific path rather than from a read-only system location, the registry allows multiple users to share the same machine, and also allows programs to work for less privileged users. Backup and restoration is also simplified as the registry can be accessed over a network connection for remote management/support, including from scripts, using the standard set of APIs, as long as the Remote Registry service is running and firewall rules permit this.
Because the registry is a database, it offers improved system integrity with features such as atomic updates. If two processes attempt to update the same registry value at the same time, one process's change will precede the other's and the overall consistency of the data will be maintained. Where changes are made to.INI files, such race conditions can result in inconsistent data that does not match either attempted update. Windows Vista and later operating systems provide transactional updates to the registry by means of the Kernel Transaction Manager, extending the atomicity guarantees across multiple key or value changes with traditional commit–abort semantics.

Structure of Registry Key

Keys and values

The registry contains two basic elements: keys and values. Registry keys are container objects similar to folders. Registry values are non-container objects similar to files. Keys may contain values and subkeys. Keys are referenced with a syntax similar to Windows' path names, using backslashes to indicate levels of hierarchy. Keys must have a case insensitive name without backslashes.
The hierarchy of registry keys can only be accessed from a known root key handle that is mapped to the content of a registry key preloaded by the kernel from a stored "hive", or to the content of a subkey within another root key, or mapped to a registered service or DLL that provides access to its contained subkeys and values.
E.g. refers to the subkey "Windows" of the subkey "Microsoft" of the subkey "Software" of the HKEY_LOCAL_MACHINE root key.
There are seven predefined root keys, traditionally named according to their constant handles defined in the Win32 API, or by synonymous abbreviations :

HKEY_LOCAL_MACHINE or HKLM
HKEY_CURRENT_CONFIG or HKCC
HKEY_CLASSES_ROOT or HKCR
HKEY_CURRENT_USER or HKCU
HKEY_USERS or HKU
HKEY_PERFORMANCE_DATA
HKEY_DYN_DATA

Like other files and services in Windows, all registry keys may be restricted by access control lists, depending on user privileges, or on security tokens acquired by applications, or on system security policies enforced by the system. Different users, programs, services or remote systems may only see some parts of the hierarchy or distinct hierarchies from the same root keys.
Registry values are name/data pairs stored within keys. Registry values are referenced separately from registry keys. Each registry value stored in a registry key has a unique name whose letter case is not significant. The Windows API functions that query and manipulate registry values take value names separately from the key path or handle that identifies the parent key. Registry values may contain backslashes in their names, but doing so makes them difficult to distinguish from their key paths when using some legacy Windows Registry API functions.
The terminology is somewhat misleading, as each registry key is similar to an associative array, where standard terminology would refer to the name part of each registry value as a "key". The terms are a holdout from the 16-bit registry in Windows 3, in which registry keys could not contain arbitrary name/data pairs, but rather contained only one unnamed value. In this sense, the Windows 3 registry was like a single associative array, in which the keys formed a hierarchy, and the registry values were all strings. When the 32-bit registry was created, so was the additional capability of creating multiple named values per key, and the meanings of the names were somewhat distorted. For compatibility with the previous behavior, each registry key may have a "default" value, whose name is the empty string.
Each value can store arbitrary data with variable length and encoding, but which is associated with a symbolic type defining how to parse this data. The standard types are:

Type ID	Symbolic type name	Meaning and encoding of the data stored in the registry value
0		No type
1		A string value, normally stored and exposed in UTF-16LE, usually terminated by a NUL character
2		An "expandable" string value that can contain environment variables, normally stored and exposed in UTF-16LE, usually terminated by a NUL character
3		Binary data
4		A DWORD value, a 32-bit unsigned integer
5		A DWORD value, a 32-bit unsigned integer
6		A symbolic link to another registry key, specifying a root key and the path to the target key
7		A multi-string value, which is an ordered list of non-empty strings, normally stored and exposed in Unicode, each one terminated by a null character, the list being normally terminated by a second null character.
8		A resource list
9		A resource descriptor
10		A resource requirements list
11		A QWORD value, a 64-bit integer

Root keys

The keys at the root level of the hierarchical database are generally named by their Windows API definitions, which all begin with "HKEY". They are frequently abbreviated to a three- or four-letter short name starting with "HK". Technically, they are predefined handles to specific keys that are either maintained in memory, or stored in hive files stored in the local filesystem and loaded by the system kernel at boot time and then shared between all processes running on the local system, or loaded and mapped in all processes started in a user session when the user logs on the system.
The HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER nodes have a similar structure to each other; user applications typically look up their settings by first checking for them in, and if the setting is not found, look instead in the same location under the HKEY_LOCAL_MACHINE key. However, the converse may apply for administrator-enforced policy settings where HKLM may take precedence over HKCU. The Windows Logo Program has specific requirements for where different types of user data may be stored, and that the concept of least privilege be followed so that administrator-level access is not required to use an application.

HKEY_LOCAL_MACHINE (HKLM)

Abbreviated HKLM, HKEY_LOCAL_MACHINE stores settings that are specific to the local computer.
The key located by HKLM is actually not stored on disk, but maintained in memory by the system kernel in order to map all the other subkeys. Applications cannot create any additional subkeys. On Windows NT, this key contains four subkeys, "SAM", "SECURITY", "SYSTEM", and "SOFTWARE", that are loaded at boot time within their respective files located in the folder. A fifth subkey, "HARDWARE", is volatile and is created dynamically, and as such is not stored in a file. On Windows Vista and above, a sixth and seventh subkey, "COMPONENTS" and "BCD", are mapped in memory by the kernel on-demand and loaded from or from boot configuration data, on the system partition.

The "" key usually appears as empty for most users. It is used to reference all "Security Accounts Manager" databases for all domains into which the local system has been administratively authorized or configured. Each SAM database contains all built in accounts and configured accounts created and configured on the respective domain, for each account in that domain, it notably contains the user name which can be used to log on that domain, the internal unique user identifier in the domain, a cryptographic hash of each user's password for each enabled authentication protocol, the location of storage of their user registry hive, various status flags, and the list of domains into which the account was configured.
The "" key usually appears empty for most users and is linked to the Security database of the domain into which the current user is logged on. The kernel will access it to read and enforce the security policy applicable to the current user and all applications or operations executed by this user. It also contains a "SAM" subkey which is dynamically linked to the SAM database of the domain onto which the current user is logged on.
The "" key is normally only writable by users with administrative privileges on the local system. It contains information about the Windows system setup, data for the secure random number generator, the list of currently mounted devices containing a filesystem, several numbered Control Sets containing alternative configurations for system hardware drivers and services running on the local system, a "" subkey containing the status of these Control Sets, and a "" which is dynamically linked at boot time to the Control Set which is currently used on the local system. Each configured Control Set contains:
* an "Enum" subkey enumerating all known Plug-and-Play devices and associating them with installed system drivers,
* a "Services" subkey listing all installed system drivers and all programs running as services,
* a "Control" subkey organizing the various hardware drivers and programs running as services and all other system-wide configuration,
* a "Hardware Profiles" subkey enumerating the various profiles that have been tuned as well as the subkey which is dynamically linked to one of these profiles.
The "" subkey contains software and Windows settings. It is mostly modified by application and system installers. It is organized by software vendor, but also contains a "Windows" subkey for some settings of the Windows user interface, a "Classes" subkey containing all registered associations from file extensions, MIME types, Object Classes IDs and interfaces IDs, to the installed applications or DLLs that may be handling these types on the local machine, and a "Policies" subkey for enforcing general usage policies on applications and system services.
The "" key is used by 32-bit applications on a 64-bit Windows OS, and is equivalent to but separate from "". The key path is transparently presented to 32-bit applications by WoW64 as