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 interface 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 rationalise and centralise 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 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 and/or value changes, with traditional commit–abort semantics.

Structure

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. HKEY_LOCAL_MACHINE\Software\Microsoft\Windows 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 :
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 and/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 IDSymbolic type nameMeaning and encoding of the data stored in the registry value
0REG_NONENo type
1REG_SZA string value, normally stored and exposed in UTF-16LE, usually terminated by a NUL character
2REG_EXPAND_SZAn "expandable" string value that can contain environment variables, normally stored and exposed in UTF-16LE, usually terminated by a NUL character
3REG_BINARYBinary data
4REG_DWORD / REG_DWORD_LITTLE_ENDIANA DWORD value, a 32-bit unsigned integer
5REG_DWORD_BIG_ENDIANA DWORD value, a 32-bit unsigned integer
6REG_LINKA symbolic link to another registry key, specifying a root key and the path to the target key
7REG_MULTI_SZA multi-string value, which is an ordered list of non-empty strings, normally stored and exposed in UTF-16LE, each one terminated by a NUL character, the list being normally terminated by a second NUL character.
8REG_RESOURCE_LISTA resource list
9REG_FULL_RESOURCE_DESCRIPTORA resource descriptor
10REG_RESOURCE_REQUIREMENTS_LISTA resource requirements list
11REG_QWORD / REG_QWORD_LITTLE_ENDIANA 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 "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 "HKEY_CURRENT_USER\Software\Vendor's name\Application's name\Version\Setting name", 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 %SystemRoot%\System32\config 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 %SystemRoot%\system32\config\COMPONENTS or from boot configuration data, \boot\BCD on the system partition.

HKEY_CLASSES_ROOT (HKCR)

HKEY_USERS (HKU)

HKEY_CURRENT_USER (HKCU)

HKEY_PERFORMANCE_DATA

HKEY_DYN_DATA

Hives

Even though the registry presents itself as an integrated hierarchical database, branches of the registry are actually stored in a number of disk files called hives.
Some hives are volatile and are not stored on disk at all. An example of this is the hive of the branch starting at HKLM\HARDWARE. This hive records information about system hardware and is created each time the system boots and performs hardware detection.
Individual settings for users on a system are stored in a hive per user. During user login, the system loads the user hive under the HKEY_USERS key and sets the HKCU symbolic reference to point to the current user. This allows applications to store/retrieve settings for the current user implicitly under the HKCU key.
Not all hives are loaded at any one time. At boot time, only a minimal set of hives are loaded, and after that, hives are loaded as the operating system initializes and as users log in or whenever a hive is explicitly loaded by an application.

File locations

The registry is physically stored in several files, which are generally obfuscated from the user-mode APIs used to manipulate the data inside the registry. Depending upon the version of Windows, there will be different files and different locations for these files, but they are all on the local machine. The location for system registry files in Windows NT is %SystemRoot%\System32\Config; the user-specific HKEY_CURRENT_USER user registry hive is stored in Ntuser.dat inside the user profile. There is one of these per user; if a user has a roaming profile, then this file will be copied to and from a server at logout and login respectively. A second user-specific registry file named UsrClass.dat contains COM registry entries and does not roam by default.

Windows NT

Windows NT systems store the registry in a binary file format which can be exported, loaded and unloaded by the Registry Editor in these operating systems. The following system registry files are stored in %SystemRoot%\System32\Config\:
The following file is stored in each user's profile folder:
For Windows 2000, Server 2003 and Windows XP, the following additional user-specific file is used for file associations and COM information:
For Windows Vista and later, the path was changed to:
Windows 2000 keeps an alternate copy of the registry hives and attempts to switch to it when corruption is detected. Windows XP and Windows Server 2003 do not maintain a System.alt hive because NTLDR on those versions of Windows can process the System.log file to bring up to date a System hive that has become inconsistent during a shutdown or crash. In addition, the %SystemRoot%\Repair folder contains a copy of the system's registry hives that were created after installation and the first successful startup of Windows.
Each registry data file has an associated file with a ".log" extension that acts as a transaction log that is used to ensure that any interrupted updates can be completed upon next startup. Internally, Registry files are split into 4 kB "bins" that contain collections of "cells".

Windows 9x

The registry files are stored in the %WINDIR% directory under the names USER.DAT and SYSTEM.DAT with the addition of CLASSES.DAT in Windows ME. Also, each user profile has its own USER.DAT file which is located in the user's profile directory in %WINDIR%\Profiles\<Username>\.

Windows 3.11

The only registry file is called REG.DAT and it is stored in the %WINDIR% directory.

Windows 10 Mobile

Note: To access the registry files, the Phone needs to be set in a special mode using either:
If any of above Methods worked - The Device Registry Files can be found in the following location:
\EFIESP\Windows\System32\config
Note: InterOp Tools also includes a registry editor.

Editing

Registry editors

The registry contains important configuration information for the operating system, for installed applications as well as individual settings for each user and application. A careless change to the operating system configuration in the registry could cause irreversible damage, so it is usually only installer programs which perform changes to the registry database during installation/configuration and removal. If a user wants to edit the registry manually, Microsoft recommends that a backup of the registry be performed before the change. When a program is removed from control panel, it is not completely removed and the user must manually check inside directories such as program files. After this, the user needs to manually remove any reference to the uninstalled program in the registry. This is usually done by using RegEdit.exe. Editing the registry is sometimes necessary when working around Windows-specific issues e.g. problems when logging onto a domain can be resolved by editing the registry.
Windows Registry can be edited manually using programs such as RegEdit.exe, although these tools do not expose some of the registry's metadata such as the last modified date.
The registry editor for the 3.1/95 series of operating systems is RegEdit.exe and for Windows NT it is RegEdt32.exe; the functionalities are merged in Windows XP. Optional and/or third-party tools similar to RegEdit.exe are available for many Windows CE versions.
Registry Editor allows users to perform the following functions:
.REG files are text-based human-readable files for exporting and importing portions of the registry. On Windows 2000 and later, they contain the string Windows Registry Editor Version 5.00 at the beginning and are Unicode-based. On Windows 9x and NT 4.0 systems, they contain the string REGEDIT4 and are ANSI-based. Windows 9x format.REG files are compatible with Windows 2000 and later. The Registry Editor on Windows on these systems also supports exporting.REG files in Windows 9x/NT format. Data is stored in.REG files using the following syntax:

"Value name"=:

The Default Value of a key can be edited by using "@" instead of "Value Name":

@=:

String values do not require a <Value type>, but backslashes need to be written as a double-backslash, and quotes as backslash-quote.
For example, to add the values "Value A", "Value B", "Value C", "Value D", "Value E", "Value F", "Value G", "Value H", "Value I", "Value J", "Value K", "Value L", and "Value M" to the HKLM\SOFTWARE\Foobar key:

Windows Registry Editor Version 5.00
"Value A"=""
"Value B"=hex:
"Value C"=dword:
"Value D"=hex:
"Value E"=hex:
"Value F"=hex:
"Value G"=hex: ; equal to "Value B"
"Value H"=hex:
"Value I"=hex:
"Value J"=hex:
"Value K"=hex:
"Value L"=hex:
"Value M"=hex:

Data from.REG files can be added/merged with the registry by double-clicking these files or using the /s switch in the command line. REG files can also be used to remove registry data.
To remove a key, the key name must be preceded by a minus sign.
For example, to remove the HKLM\SOFTWARE\Foobar key,


To remove a value, the values to be removed must have a minus sign after the equal sign.
For example, to remove only the "Value A" and "Value B" values from the HKLM\SOFTWARE\Foobar key:

"Value A"=-
"Value B"=-

To remove only the Default value of the key HKLM\SOFTWARE\Foobar :

@=-

Lines beginning with a semicolon are considered comments:

; This is a comment. This can be placed in any part of a.reg file
"Value"="Example string"

Group policies

Windows group policies can change registry keys for a number of machines or individual users based on policies. When a policy first takes effect for a machine or for an individual user of a machine, the registry settings specified as part of the policy are applied to the machine or user settings.
Windows will also look for updated policies and apply them periodically, typically every 90 minutes.
Through its scope a policy defines which machines and/or users the policy is to be applied to. Whether a machine or user is within the scope of a policy or not is defined by a set of rules which can filter on the location of the machine or user account in organizational directory, specific users or machine accounts or security groups. More advanced rules can be set up using Windows Management Instrumentation expressions. Such rules can filter on properties such as computer vendor name, CPU architecture, installed software, or networks connected to.
For instance, the administrator can create a policy with one set of registry settings for machines in the accounting department and policy with another set of registry settings for kiosk terminals in the visitors area. When a machine is moved from one scope to another, the correct policy is automatically applied. When a policy is changed it is automatically re-applied to all machines currently in its scope.
The policy is edited through a number of administrative templates which provides a user interface for picking and changing settings. The set of administrative templates is extensible and software packages which support such remote administration can register their own templates.

Command line editing

The registry can be manipulated in a number of ways from the command line. The Reg.exe and RegIni.exe utility tools are included in Windows XP and later versions of Windows. Alternative locations for legacy versions of Windows include the Resource Kit CDs or the original Installation CD of Windows.
Also, a .REG file can be imported from the command line with the following command:
RegEdit.exe /s file
The /s means the file will be silent merged to the registry. If the /s parameter is omitted the user will be asked to confirm the operation. In Windows 98, Windows 95 and at least some configurations of Windows XP the /s switch also causes RegEdit.exe to ignore the setting in the registry that allows administrators to disable it. When using the /s switch RegEdit.exe does not return an appropriate return code if the operation fails, unlike Reg.exe which does.
RegEdit.exe /e file
exports the whole registry in V5 format to a UNICODE .REG file, while any of
RegEdit.exe /e file HKEY_CLASSES_ROOT
RegEdit.exe /e file HKEY_CURRENT_CONFIG
RegEdit.exe /e file HKEY_CURRENT_USER
RegEdit.exe /e file HKEY_LOCAL_MACHINE
RegEdit.exe /e file HKEY_USERS
export the specified key only.
RegEdit.exe /a file
exports the whole registry in V4 format to an ANSI .REG file.
RegEdit.exe /a file <key>
exports the specified key only.
It is also possible to use Reg.exe. Here is a sample to display the value of the registry value Version:

Reg.exe QUERY HKLM\Software\Microsoft\ResKit /v Version

Other command line options include a VBScript or JScript together with CScript, WMI or WMIC.exe and Windows PowerShell.
Registry permissions can be manipulated through the command line using RegIni.exe and the tool. For example, the permissions on the HKEY_LOCAL_MACHINE\SOFTWARE key can be displayed using:

SubInACL.exe /keyreg HKEY_LOCAL_MACHINE\SOFTWARE /display

PowerShell commands and scripts

comes with a registry provider which presents the registry as a location type similar to the file system. The same commands used to manipulate files/directories in the file system can be used to manipulate keys/values of the registry.
Also like the file system, PowerShell uses the concept of a current location which defines the context on which commands by default operate. The Get-ChildItem retrieves the child keys of the current location. By using the Set-Location command the user can change the current location to another key of the registry. Commands which rename items, remove items, create new items or set content of items or properties can be used to rename keys, remove keys or entire sub-trees or change values.
Through PowerShell scripts files a user/administrator can prepare scripts which, when executed, make changes to the registry. Such scripts can be distributed to users/administrators who can execute them on individual machines.
The PowerShell Registry provider supports transactions, i.e. multiple changes to the registry can be bundled into a single atomic transaction. An atomic transaction ensures that either all of the changes are committed to the database, or if the script fails, none of the changes are committed to the database.

Programs or scripts

The registry can be edited through the APIs of the Advanced Windows 32 Base API Library.
Many programming languages offer built-in runtime library functions or classes that wrap the underlying Windows APIs and thereby enable programs to store settings in the registry. COM-enabled applications like Visual Basic 6 can use the WSH WScript.Shell object. Another way is to use the Windows Resource Kit Tool, Reg.exe by executing it from code, although this is considered poor programming practice.
Similarly, scripting languages such as Perl, Python, TCL, Windows Powershell and Windows Scripting Host also enable registry editing from scripts.

Offline editing

The offreg.dll available from the Windows Driver Kit offers a set of APIs for the creation and manipulation of currently not loaded registry hives similar to those provided by advapi32.dll.
It is also possible to edit the registry of an offline system from Windows PE or Linux.

COM self-registration

Prior to the introduction of registration-free COM, developers were encouraged to add initialization code to in-process and out-of-process binaries to perform the registry configuration required for that object to work. For in-process binaries such as.DLL and.OCX files, the modules typically exported a function called DllInstall that could be called by installation programs or invoked manually with utilities like Regsvr32.exe; out-of-process binaries typically support the commandline arguments /Regserver and /Unregserver that created or deleted the required registry settings. COM applications that break because of DLL Hell issues can commonly be repaired with RegSvr32.exe or the /RegServer switch without having to re-invoke installation programs.

Advanced functionality

Windows exposes APIs that allows user-mode applications to register to receive a notification event if a particular registry key is changed. APIs are also available to allow kernel-mode applications to filter and modify registry calls made by other applications.
Windows also supports remote access to the registry of another computer via the RegConnectRegistry function if the Remote Registry service is running, correctly configured and its network traffic is not firewalled.

Security

Each key in the registry of Windows NT versions can have an associated security descriptor. The security descriptor contains an access control list that describes which user groups or individual users are granted or denied access permissions. The set of registry permissions include 10 rights/permissions which can be explicitly allowed or denied to a user or a group of users.
PermissionDescription
Query ValueThe right to read the registry key value.
Set ValueThe right to write a new value
Create SubkeyThe right to create subkeys.
Enumerate SubkeysAllow the enumeration of subkeys.
NotifyThe right to request change notifications for registry keys or subkeys.
Create LinkReserved by the operating system.
DeleteThe right to delete a key.
Write DACLThe right to modify permissions of the container's DACL.
Write OwnerThe right to modify the container's owner.
Read ControlThe right to read the DACL.

As with other securable objects in the operating system, individual access control entries on the security descriptor can be explicit or inherited from a parent object.
Windows Resource Protection is a feature of Windows Vista and later versions of Windows that uses security to deny Administrators and the system WRITE access to some sensitive keys to protect the integrity of the system from malware and accidental modification.
Special ACEs on the security descriptor can also implement mandatory integrity control for the registry key and subkeys. A process running at a lower integrity level cannot write, change or delete a registry key/value, even if the account of the process has otherwise been granted access through the ACL. For instance, Internet Explorer running in Protected Mode can read medium and low integrity registry keys/values of the currently logged on user, but it can only modify low integrity keys.
Outside security, registry keys cannot be deleted or edited due to other causes. Registry keys containing NUL characters cannot be deleted with standard registry editors and require a special utility for deletion, such as RegDelNull.

Backups and recovery

Different editions of Windows have supported a number of different methods to back up and restore the registry over the years, some of which are now deprecated:

Group policy

Windows 2000 and later versions of Windows use Group Policy to enforce registry settings through a registry-specific client extension in the Group Policy processing engine. Policy may be applied locally to a single computer using gpedit.msc, or to multiple users and/or computers in a domain using gpmc.msc.

Legacy systems

With Windows 95, Windows 98, Windows ME and Windows NT 4.0, administrators can use a special file to be merged into the registry, called a policy file. The policy file allows administrators to prevent non-administrator users from changing registry settings like, for instance, the security level of Internet Explorer and the desktop background wallpaper. The policy file is primarily used in a business with a large number of computers where the business needs to be protected from rogue or careless users.
The default extension for the policy file is .POL.
The policy file filters the settings it enforces by user and by group. To do that the policy file merges into the registry, preventing users from circumventing it by simply changing back the settings.
The policy file is usually distributed through a LAN, but can be placed on the local computer.
The policy file is created by a free tool by Microsoft that goes by the filename poledit.exe for Windows 95/Windows 98 and with a computer management module for Windows NT. The editor requires administrative permissions to be run on systems that uses permissions.
The editor can also directly change the current registry settings of the local computer and if the remote registry service is installed and started on another computer it can also change the registry on that computer.
The policy editor loads the settings it can change from .ADM files, of which one is included, that contains the settings the Windows shell provides. The .ADM file is plain text and supports easy localisation by allowing all the strings to be stored in one place.

Virtualization

INI file virtualization

Windows NT kernels support redirection of INI file-related APIs into a virtual file in a registry location such as HKEY_CURRENT_USER using a feature called "InifileMapping". This functionality was introduced to allow legacy applications written for 16-bit versions of Windows to be able to run under Windows NT platforms on which the System folder is no longer considered an appropriate location for user-specific data or configuration. Non-compliant 32-bit applications can also be redirected in this manner, even though the feature was originally intended for 16-bit applications.

Registry virtualization

introduced limited registry virtualization, whereby poorly written applications that do not respect the principle of least privilege and instead try to write user data to a read-only system location, are silently redirected to a more appropriate location, without changing the application itself.
Similarly, application virtualization redirects all of an application's invalid registry operations to a location such as a file. Used together with file virtualization, this allows applications to run on a machine without being installed on it.
Low integrity processes may also use registry virtualization. For example, Internet Explorer 7 or 8 running in "Protected Mode" on Windows Vista and above will automatically redirect registry writes by ActiveX controls to a sandboxed location in order to frustrate some classes of security exploits.
The Application Compatibility Toolkit provides shims that can transparently redirect HKEY_LOCAL_MACHINE or HKEY_CLASSES_ROOT Registry operations to HKEY_CURRENT_USER to address "LUA" bugs that cause applications not to work for users with insufficient rights.

Disadvantages

Critics labeled the registry in Windows 95 a single point of failure, because re-installation of the operating system was required if the registry became corrupt. However, Windows NT uses transaction logs to protect against corruption during updates. Current versions of Windows use two levels of log files to ensure integrity even in the case of power failure or similar catastrophic events during database updates. Even in the case of a non-recoverable error, Windows can repair or re-initialize damaged registry entries during system boot.

Equivalents and alternatives

In Windows, use of the registry for storing program data is a matter of developer's discretion. Microsoft provides programming interfaces for storing data in XML files or database files which developers can use instead. Developers are also free to use non-Microsoft alternatives or develop their own proprietary data stores.
In contrast to Windows Registry's binary-based database model, some other operating systems use separate plain-text files for daemon and application configuration, but group these configurations together for ease of management.