Editing Windows Registry (section)

== 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 sensitivity|case insensitive]] name without backslashes.

The hierarchy of registry keys can only be accessed from a known root key handle (which is anonymous but whose effective value is a constant numeric 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. {{code|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 (depending on applications):{{Sfn|Hipson|2002|p=5, 41–43}}
* 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 (only in Windows NT, but invisible in the Windows Registry Editor)<ref>{{cite book|url=https://books.google.com/books?id=r5tCAwAAQBAJ&pg=PT260|title=Windows Via C/C++|last1=Richter|first1=Jeffrey|last2=Nasarre|first2=Christophe|publisher=[[Microsoft Press]]|date=2008|access-date=August 28, 2021|edition=Fifth|isbn=9780735642461}}</ref>
* HKEY_DYN_DATA (only in Windows 9x, and visible in the Windows Registry Editor)

Like other files and services in Windows, all registry keys may be restricted by [[access control list]]s (ACLs), depending on user privileges, or on security tokens acquired by applications, or on system security policies enforced by the system (these restrictions may be predefined by the system itself, and configured by local system administrators or by domain administrators). 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 (whose usage is deprecated in Win32).

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 (which had to be a string). In this sense, the Windows 3 registry was like a single associative array, in which the keys (in the sense of both 'registry key' and 'associative array key') 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.<ref>[[Raymond Chen]], [https://devblogs.microsoft.com/oldnewthing/20080118-00/?p=23773 "Why do registry keys have a default value?"]</ref> 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 (defined as a numeric constant) defining how to parse this data. The standard types are:{{Sfn|Hipson|2002|pp=207, 513–514}}

{|class="wikitable"
|+ List of standard registry value types
|-
! Type ID  !! Symbolic type name !! Meaning and encoding of the data stored in the registry value
|-
| 0 || {{mono|REG_NONE}} || No type (the stored value, if any)
|-
| 1 || {{mono|REG_SZ}} || A [[string (computer science)|string]] value, normally stored and exposed in [[UTF-16]]LE (when using the Unicode version of Win32 API functions), usually terminated by a NUL character
|-
| 2 || {{mono|REG_EXPAND_SZ}} || An "expandable" string value that can contain [[environment variable]]s, normally stored and exposed in UTF-16LE, usually terminated by a NUL character
|-
| 3 || {{mono|REG_BINARY}} || Binary data (any arbitrary data)
|-
| 4 || {{mono|REG_DWORD / REG_DWORD_LITTLE_ENDIAN}} || A [[Dword (Computer)|DWORD]] value, a 32-bit [[Signedness|unsigned]] [[integer]] (numbers between 0 and 4,294,967,295 [2<sup>32</sup> – 1]) (little-[[Endianness|endian]])
|-
| 5 || {{mono|REG_DWORD_BIG_ENDIAN}} || A [[Dword (Computer)|DWORD]] value, a 32-bit [[Signedness|unsigned]] [[integer]] (numbers between 0 and 4,294,967,295 [2<sup>32</sup> – 1]) (big-[[Endianness|endian]])
|-
| 6 || {{mono|REG_LINK}} || A symbolic link (UNICODE) to another registry key, specifying a root key and the path to the target key
|-
| 7 || {{mono|REG_MULTI_SZ}} || A multi-string value, which is an ordered list of non-empty [[string (computer science)|strings]], normally stored and exposed in Unicode, each one terminated by a null character, the list being normally terminated by a second null character.{{Sfn|Hipson|2002|pp=520–521}}
|-
| 8 || {{mono|REG_RESOURCE_LIST}} || A resource list (used by the ''Plug-n-Play'' hardware enumeration and configuration)
|-
| 9 || {{mono|REG_FULL_RESOURCE_DESCRIPTOR}} || A resource descriptor (used by the ''Plug-n-Play'' hardware enumeration and configuration)
|-
| 10 || {{mono|REG_RESOURCE_REQUIREMENTS_LIST}} || A resource requirements list (used by the ''Plug-n-Play'' hardware enumeration and configuration)
|-
| 11 || {{mono|REG_QWORD / REG_QWORD_LITTLE_ENDIAN}} || A [[Word_(computer_architecture)#Size_families|QWORD]] value, a 64-bit integer (either big- or little-endian, or unspecified) (introduced in [[Windows 2000]]){{Sfn|Hipson|2002|p=7}}
|}

=== 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".<ref name=SystemRegistry /> They are frequently abbreviated to a three- or four-letter short name starting with "HK" (e.g. HKCU and HKLM). Technically, they are predefined handles (with known constant values) 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 (with various access rights) 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 (local machine-specific configuration data) and HKEY_CURRENT_USER (user-specific configuration data) nodes have a similar structure to each other; user applications typically look up their settings by first checking for them in {{code|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 [[Group Policy|policy]] settings where HKLM may take precedence over HKCU. The [[WHQL Testing|Windows Logo Program]] has specific requirements for where different types of user data may be stored, and that the concept of [[Principle of least privilege|least privilege]] be followed so that administrator-level access is not required to use an application.{{efn|When applications fail to execute because they request more privileges than they require (and are denied those privileges), this is known as a limited user application (LUA) bug.}}<ref>{{cite web|publisher=[[Microsoft]]|title=Designed for Windows XP Application Specification|url=http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=209e3d65-f0be-4eef-8602-73bb9bc29d54|date=2002-08-20|access-date=2009-04-08}}</ref>

====HKEY_LOCAL_MACHINE (HKLM)====
Abbreviated HKLM, HKEY_LOCAL_MACHINE stores settings that are specific to the local computer.<ref>{{cite web|url=https://technet.microsoft.com/en-us/library/cc959046.aspx|title=HKEY_LOCAL_MACHINE|publisher=Gautam|year=2009|access-date=2009-04-08}}</ref>

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 {{code|%SystemRoot%\System32\config\}} folder. A fifth subkey, "HARDWARE", is volatile and is created dynamically, and as such is not stored in a file (it exposes a view of all the currently detected Plug-and-Play devices). 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 {{code|%SystemRoot%\System32\config\COMPONENTS}} or from boot configuration data, {{code|\boot\BCD}} on the system partition.

* The "{{code|HKLM\SAM}}" key usually appears as empty for most users (unless they are granted access by administrators of the local system or administrators of domains managing the local system). It is used to reference all "[[Security Accounts Manager]]" (SAM) databases for all domains into which the local system has been administratively authorized or configured (including the local domain of the running system, whose SAM database is stored in a subkey also named "SAM": other subkeys will be created as needed, one for each supplementary domain). Each SAM database contains all builtin accounts (mostly group aliases) and configured accounts (users, groups and their aliases, including guest accounts and administrator 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 function|cryptographic hash]] of each user's password for each enabled [[authentication protocol]], the location of storage of their user registry hive, various status flags (for example if the account can be enumerated and be visible in the logon prompt screen), and the list of domains (including the local domain) into which the account was configured.
* The "{{code|HKLM\SECURITY}}" key usually appears empty for most users (unless they are granted access by users with administrative privileges) and is linked to the Security database of the domain into which the current user is logged on (if the user is logged on the local system domain, this key will be linked to the registry hive stored by the local machine and managed by local system administrators or by the builtin "System" account and Windows installers). 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 "{{code|HKLM\SYSTEM}}" 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 (RNG), the list of currently mounted devices containing a filesystem, several numbered {{code|HKLM\SYSTEM\Control Sets}} containing alternative configurations for system hardware drivers and services running on the local system (including the currently used one and a backup), a "{{code|HKLM\SYSTEM\Select}}" subkey containing the status of these Control Sets, and a "{{code|HKLM\SYSTEM\CurrentControlSet}}" 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 (and storing the device-specific configurations of these drivers),
** a "Services" subkey listing all installed system drivers (with non device-specific configuration, and the enumeration of devices for which they are instantiated) and all programs running as services (how and when they can be automatically started),
** 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 (each one with "System" or "Software" settings used to modify the default profile, either in system drivers and services or in the applications) as well as the {{code|Hardware Profiles\Current}} subkey which is dynamically linked to one of these profiles.
* The "{{code|HKLM\SOFTWARE}}" subkey contains software and Windows settings (in the default hardware profile). It is mostly modified by application and system installers. It is organized by software vendor (with a subkey for each), 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 (for OLE, COM/DCOM and ActiveX), to the installed applications or DLLs that may be handling these types on the local machine (however these associations are configurable for each user, see below), and a "Policies" subkey (also organized by vendor) for enforcing general usage policies on applications and system services (including the central certificates store used for authenticating, authorizing or disallowing remote systems or services running outside the local network domain).
* The "{{code|HKLM\SOFTWARE\Wow6432Node}}" key is used by 32-bit applications on a 64-bit Windows OS, and is equivalent to but separate from "{{code|HKLM\SOFTWARE}}". The key path is transparently presented to 32-bit applications by [[WoW64]] as {{code|HKLM\SOFTWARE}}<ref>{{cite web|url=https://msdn.microsoft.com/en-us/library/aa384253.aspx |title=Registry Keys Affected by WOW64 (Windows) |publisher=Msdn.microsoft.com |access-date=2014-04-10}}</ref> (in a similar way that 64-bit applications see {{code|%SystemRoot%\Syswow64}} as {{code|%SystemRoot%\System32}})

====HKEY_CLASSES_ROOT (HKCR)====
:Abbreviated HKCR, HKEY_CLASSES_ROOT contains information about registered applications, such as [[file association]]s and [[Object linking and embedding|OLE]] Object Class IDs, tying them to the applications used to handle these items. On [[Windows 2000]] and above, HKCR is a compilation of user-based {{code|HKCU\Software\Classes}} and machine-based {{code|HKLM\Software\Classes}}. If a given value exists in both of the subkeys above, the one in {{code|HKCU\Software\Classes}} takes precedence.<ref>{{cite web| URL = http://support.microsoft.com/kb/256986 | title = Description of the Microsoft Windows registry | access-date = 2008-09-25 }}</ref> The design allows for either machine- or user-specific registration of [[Component Object Model|COM]] objects.<!-- The user-specific classes hive, unlike the HKCU hive, does not form part of a roaming user profile. -->

====HKEY_USERS (HKU)====
:Abbreviated HKU, HKEY_USERS contains subkeys corresponding to the HKEY_CURRENT_USER keys for each user profile actively loaded on the machine, though user hives are usually only loaded for currently logged-in users.

====HKEY_CURRENT_USER (HKCU)====
:Abbreviated HKCU, HKEY_CURRENT_USER stores settings that are specific to the currently logged-in user.<ref>{{cite web| url = https://technet.microsoft.com/en-us/library/cc976337.aspx | title = HKEY_CURRENT_USER | year = 2009 | publisher = [[Microsoft]] | access-date = 2009-04-08 }}</ref> The HKEY_CURRENT_USER key is a link to the subkey of HKEY_USERS that corresponds to the user; the same information is accessible in both locations. The specific subkey referenced is {{code|(HKU)\(SID)\...}} where (SID) corresponds to the [[Windows SID]]; if the "(HKCU)" key has the following suffix {{code|(HKCU)\Software\Classes\...}} then it corresponds to {{code|(HKU)\(SID)_CLASSES\...}} i.e. the suffix string "_CLASSES" is appended to the (SID).

:On Windows NT systems, each user's settings are stored in their own files called NTUSER.DAT and USRCLASS.DAT inside their own Documents and Settings subfolder (or their own Users sub folder in Windows Vista and above). Settings in this hive follow users with a [[Roaming user profile|roaming profile]] from machine to machine.

====HKEY_PERFORMANCE_DATA====
:This key provides runtime information into performance data provided by either the NT kernel itself, or running system drivers, programs and services that provide performance data. This key is not stored in any hive and not displayed in the Registry Editor, but it is visible through the registry functions in the Windows API, or in a simplified view via the Performance tab of the Task Manager (only for a few performance data on the local system) or via more advanced control panels (such as the Performances Monitor or the Performances Analyzer which allows collecting and logging these data, including from remote systems).

====HKEY_DYN_DATA====
:This key is used only in Windows 95, [[Windows 98]] and [[Windows ME]].<ref>{{Cite web|url=http://support.microsoft.com/kb/250568|title=Description of the HKEY_DYN_DATA Registry Key in Windows 95, Windows 98, and Windows 98 SE|website=support.microsoft.com}}</ref> It contains information about hardware devices, including Plug and Play and network performance statistics. The information in this hive is also not stored on the hard drive; the Plug and Play information is gathered and configured at startup and is stored in memory.<ref>{{cite web|url=http://docs.rinet.ru/Registratura/htm/apf.htm|title=A Closer Look at HKEY_DYN_DATA|website=rinet.ru|url-status=dead|archive-url=https://web.archive.org/web/20080509003336/http://docs.rinet.ru/Registratura/htm/apf.htm|archive-date=2008-05-09}}</ref>

=== 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''.<ref>{{cite web | url = http://msdn2.microsoft.com/en-us/library/ms724877.aspx | title = Registry hives | access-date= 2007-07-19}}</ref> (The word hive constitutes an [[in-joke]].)<ref>{{cite web|first=Raymond|last=Chen|url=https://devblogs.microsoft.com/oldnewthing/20030808-00/?p=42943|title=Why is a registry file called a "hive"? |publisher=The Old New Thing|date=2011-08-08 |access-date=2011-07-29}}</ref>

Some hives are volatile and are not stored on disk at all. An example of this is the hive of the branch starting at {{code|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 (disk file) per user. During user login, the system loads the user hive under the HKEY_USERS key and sets the HKCU (HKEY_CURRENT_USER) 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 <code>%SystemRoot%\System32\config\</code>; the user-specific HKEY_CURRENT_USER user registry hive is stored in <code>Ntuser.dat</code> inside the user profile. There is one of these per user; if a user has a [[roaming user profile|roaming profile]], then this file will be copied to and from a [[server (computing)|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 <code>%SystemRoot%\System32\config\</code>:
* <code>Sam</code> – {{code|HKEY_LOCAL_MACHINE\SAM}}
* <code>Security</code> – {{code|HKEY_LOCAL_MACHINE\SECURITY}}
* <code>Software</code> – {{code|HKEY_LOCAL_MACHINE\SOFTWARE}}
* <code>System</code> – {{code|HKEY_LOCAL_MACHINE\SYSTEM}}
* <code>Default</code> – {{code|HKEY_USERS\.DEFAULT}}
* <code>Userdiff</code> – Not associated with a hive. Used only when upgrading operating systems.<ref>{{cite web | url = https://technet.microsoft.com/en-us/library/cc722562.aspx | title = Overview of the Windows NT Registry | access-date = 2011-12-02}}</ref>

The following file is stored in each user's profile folder:
* <code>%USERPROFILE%\Ntuser.dat</code> – <code>HKEY_USERS\<[[Security Identifier|User SID]]></code> (linked to by HKEY_CURRENT_USER)

For Windows 2000, Server 2003 and Windows XP, the following additional user-specific file is used for file associations and COM information:
* <code>%USERPROFILE%\Local Settings\Application Data\Microsoft\Windows\Usrclass.dat</code> (path is localized) – <code>HKEY_USERS\&lt;User SID&gt;_Classes</code> ({{code|HKEY_CURRENT_USER\Software\Classes}})
For Windows Vista and later, the path was changed to:
* <code>%USERPROFILE%\AppData\Local\Microsoft\Windows\Usrclass.dat</code> (path is not localized) alias <code>%LocalAppData%\Microsoft\Windows\Usrclass.dat</code> – HKEY_USERS\&lt;User SID&gt;_Classes ({{code|HKEY_CURRENT_USER\Software\Classes}})

Windows 2000 keeps an alternate copy of the registry hives (.ALT) and attempts to switch to it when corruption is detected.<ref>{{cite web | url = https://technet.microsoft.com/en-us/library/cc750583.aspx | title = Inside the Registry | access-date = 2007-12-28}}</ref> Windows XP and Windows Server 2003 do not maintain a <code>System.alt</code> hive because [[NTLDR]] on those versions of Windows can process the <code>System.log</code> file to bring up to date a System hive that has become inconsistent during a shutdown or crash. In addition, the <code>%SystemRoot%\Repair</code> 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.<ref name="Norris">{{cite web|archive-url=https://web.archive.org/web/20090529202753/http://amnesia.gtisc.gatech.edu/~moyix/suzibandit.ltd.uk/MSc/Registry%20Structure%20-%20Main%20V4.pdf|format=PDF|url=http://amnesia.gtisc.gatech.edu/~moyix/suzibandit.ltd.uk/MSc/|date=February 2009|title=The Internal Structure of the Windows Registry|publisher=Cranfield University|archive-date=29 May 2009|last=Norris|first=Peter|url-status=dead}}</ref>  Internally, Registry files are split into 4&nbsp;[[Kilobyte|kB]] "bins" that contain collections of "cells".<ref name="Norris" />

==== Windows 9x ====
The registry files are stored in the <code>%WINDIR%</code> directory under the names <code>USER.DAT</code> and <code>SYSTEM.DAT</code> with the addition of <code>CLASSES.DAT</code> in Windows ME. Also, each user profile (if profiles are enabled) has its own <code>USER.DAT</code> file which is located in the user's profile directory in <code>%WINDIR%\Profiles\&lt;Username&gt;\</code>.

==== Windows 3.11 ====
The only registry file is called <code>REG.DAT</code> and it is stored in the <code>%WINDIR%</code> directory.

==== Windows 10 Mobile ====
To access the registry files, the device needs to be set in a special mode using either:&nbsp;

* [https://www.wpinternals.net/ WpInternals] (Put the device into flash mode.)
* [https://www.microsoft.com/en-us/p/interop-tools-store/9nj3rs1t5n68 InterOp Tools] (Mount the MainOS Partition with MTP.)

If any of the above methods worked, the device's registry files can be found in the following location:
  {Phone}\EFIESP\Windows\System32\config