The Windows Registry is a database that stores settings and options for Microsoft Windows operating systems. It contains information and settings for hardware, operating system software, most non-operating system software, and per-user settings. The registry also provides a window into the operation of the kernel, exposing runtime information such as performance counters and currently active hardware.
When first introduced with Windows 3.1, the Windows registry's purpose was to tidy up the profusion of per-program INI files that had previously been used to store configuration settings for Windows programs.
- 1 Structure
- 2 Editing
- 3 Locations
- 4 Backups and recovery
- 5 Policy
- 6 .INI file virtualization
- 7 Registry virtualization
- 8 Equivalents in other operating systems
- 9 Advantages and disadvantages
- 10 See also
- 11 Notes
- 12 Footnotes
- 13 References
- 14 External links
Keys and values
The registry contains two basic elements: keys and values.
Registry Keys are similar to folders - in addition to values, each key can contain subkeys, which may contain further subkeys, and so on. Keys are referenced with a syntax similar to Windows' path names, using backslashes to indicate levels of hierarchy. For example, HKEY_LOCAL_MACHINE\Software\Microsoft\Windows refers to the subkey "Windows" of the subkey "Microsoft" of the subkey "Software" of the HKEY_LOCAL_MACHINE key. There are six Root Keys:
Registry Values are name/data pairs stored within keys. Values are referenced separately from keys. Value names can contain backslashes but doing so makes them difficult to distinguish from their key paths. 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.
The terminology is somewhat misleading, as the values are similar to an associative array, where standard terminology would refer to the name part of the value as a "key". The terms are a holdout from the 16-bit registry in Windows 3, in which 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 entire registry was like an associative array where the keys (in both the registry sense and dictionary sense) formed a hierarchy, and the 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.
There are a number of different types of values:
|List of Registry Value Types
|A string value
|An "expandable" string value that can contain environment variables
|Binary data (any arbitrary data)
|A DWORD value, a 32-bit unsigned integer (numbers between 0 and 4,294,967,295 [232 – 1]) (little-endian)
|A DWORD value, a 32-bit unsigned integer (numbers between 0 and 4,294,967,295 [232 – 1]) (big-endian)
|symbolic link (UNICODE)
|A multi-string value, which is an array of unique strings
|Resource Requirements List
|A QWORD value, a 64-bit integer (either big- or little-endian, or unspecified) (Introduced in Windows 2000)
The Registry is split into a number of logical sections, or "hives" (the reason the word hive was used is an in-joke). Hives are generally named by their Windows definitions, which all begin "HKEY". They are abbreviated to a three- or four-letter short name starting with "HK" (e.g. HKCU and HKLM).
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 "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.[Note 1]
Abbreviated HKCR, HKEY_CLASSES_ROOT stores information about registered applications, such as file associations and 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 HKCU\Software\Classes and machine-based HKLM\Software\Classes. If a given value exists in both of the subkeys above, the one in HKCU\Software\Classes takes precedence. The design allows for either machine- or user-specific registration of COM objects. The user-specific classes hive, unlike the HKCU hive, does not form part of a roaming user profile.
Abbreviated HKCU, HKEY_CURRENT_USER stores settings that are specific to the currently logged-in user. The HKCU key is a link to the subkey of HKEY_USERS that corresponds to the user; the same information is accessible in both locations. On Windows-NT based 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 subfolder in Windows Vista). Settings in this hive follow users with a roaming profile from machine to machine.
Abbreviated HKLM, HKEY_LOCAL_MACHINE stores settings that are specific to the local computer. On NT-based versions of Windows, HKLM contains four subkeys, SAM, SECURITY, SOFTWARE and SYSTEM, that are found 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. Information about system hardware drivers and services are located under the SYSTEM subkey, while the SOFTWARE subkey contains software and Windows settings.
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.
Abbreviated HKCC, HKEY_CURRENT_CONFIG contains information gathered at runtime; information stored in this key is not permanently stored on disk, but rather regenerated at the boot time. It is a link to
This key provides runtime information into performance data provided by either the NT kernel itself or other programs that provide performance data. This key is not displayed in the Registry Editor, but it is visible through the registry functions in the Windows API.
This key is used only on Windows 95, Windows 98 and Windows Me. 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.
|This article may need to be updated. Please update this article to reflect recent events or newly available information, and remove this template when finished. Please see the talk page for more information.
In Windows NT based systems Symbolic Links between registry keys are supported through REG_LINK value type. Registry links work similarly to file shortcuts or filesystem Symbolic links in that they can span across different hives, but only those visible in Native API namespace, that is
\Registry\User. Other hives like HKEY_DYN_DATA are only virtual objects in Win32 API and thus not linkable. Links are used in Windows for only
Aliases in the windows 9x registry:
|User’s branch within HKEY_USERS
|Hardware profile within HKEY_LOCAL_MACHINE\Config
Accessing the Registry
Start > Run > Regedit
The registry can be edited manually in Microsoft Windows by running regedit.exe or regedt32.exe in the Windows directory. However, careless registry editing can cause irreversible damage. Thus, performing backups of the registry before editing it is highly recommended by Microsoft and many industry experts (such as the authors and editors of leading trade magazines).
A simple implementation of the current registry tool appeared in Windows 3.x, called the "Registration Info Editor" or "Registration Editor". This was basically just a database of applications used to edit embedded OLE objects in documents.
Windows 9x operating systems include REGEDIT.EXE which can be used in Windows and also in real mode MS-DOS. Windows NT introduced permissions for Registry editing. Windows NT 4.0 and Windows 2000 were distributed with both the Windows 9x REGEDIT.EXE program and Windows NT 3.x's REGEDT32.EXE program. There are several differences between the two editors on these platforms:
- REGEDIT.EXE has a left-side tree view that begins at "My Computer" and lists all loaded hives. REGEDT32.EXE has a left-side tree view, but each hive has its own window, so the tree displays only keys.
- REGEDIT.EXE represents the three components of a value (its name, type, and data) as separate columns of a table. REGEDT32.EXE represents them as a list of strings.
- REGEDIT.EXE supports right-clicking of entries in a tree view to adjust properties and other settings. REGEDT32.EXE requires all actions to be performed from the top menu bar.
- REGEDIT.EXE supports searching for key names, values, or data throughout the entire registry, whereas REGEDT32.EXE only supports searching for key names in one hive at a time.
- Because REGEDIT.EXE was directly ported from Windows 95, it does not support editing permissions. (Permissions do not exist on Windows 9x). Therefore, of the two, only REGEDT32.EXE can access the full functionality of an NT registry.
- REGEDIT.EXE only supports string (REG_SZ), binary (REG_BINARY), and DWORD (REG_DWORD) values. REGEDT32.EXE supports those, plus expandable string (REG_EXPAND_SZ) and multi-string (REG_MULTI_SZ). Attempting to edit unsupported key types with REGEDIT.EXE on Windows 2000 or Windows NT 4.0 will result in irreversible conversion to a supported type.
Windows XP was the first system to integrate these two programs into one, adopting the old REGEDIT.EXE interface and adding the REGEDT32.EXE functionality. The differences listed above are not applicable on Windows XP and newer systems; REGEDIT.EXE is the improved editor, and REGEDT32.EXE is simply a stub that invokes REGEDIT.EXE.
The Registry Editor allows users to perform the following functions:
- Creating, manipulating, renaming and deleting registry keys, subkeys, values and value data
- Importing and exporting .
REGfiles, exporting data in the binary hive format
- Loading, manipulating and unloading registry hive format files (Windows NT-based systems only)
- Setting permissions based on ACLs (Windows NT-based systems only)
- Bookmarking user-selected registry keys as Favorites
- Finding particular strings in key names, value names and value data
- Remotely editing the registry on another networked computer
REG files (also known as Registration entries) are text-based human-readable files for storing portions of the registry. On Windows 2000 and later NT-based operating systems, 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 NT-based systems. The Registry Editor on Windows on these systems also supports exporting .
REG files in Windows 9x/NT format. Data is stored in .
REG files in the following syntax: 
[<Hive Name>\<Key Name>\<Subkey Name>] "Value Name"=<Value type>:<Value data>
The Default Value of a key can be edited by using @ instead of "Value Name":
@=<Value type>:<Value data>
String values do not require a <Value type> (see example).
For example, to add the values "Value A", "Value B", "Value C", "Value D", and "Value E" to the HKLM\SOFTWARE\Microsoft key,
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft] "Value A"="<String value data>" "Value B"=hex:<Binary data> "Value C"=dword:<DWORD value integer> "Value D"=hex(7):<Multi-string value data> "Value E"=hex(2):<Expandable string value data>
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 (and all subkeys, values and data), the .
REG file must have a minus sign ("-") before the key name. 
For example, to remove the <Key Name> key (and all subkeys, values and data),
To remove a value (and its data), the .
REG file must have a minus sign ("-") after the equal sign ("=") of each value to be removed. 
For example, to remove only the "Value A" and "Value B" values (and their data) from the <Key Name> key,
[HKEY_LOCAL_MACHINE\SOFTWARE\<Key Name>] "Value A"=- "Value B"=-
To remove only the (Default) value of the key <Key Name> (and its data),
[HKEY_LOCAL_MACHINE\SOFTWARE\<Key Name>] @=-
Command line editing
The registry can be manipulated in a number of ways from the command line. The
reg.exe utility tool is 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.
.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 does not return an appropriate return code if the operation fails, unlike reg.exe which does.
The default association for
.REG files in many versions of Microsoft Windows, starting with Windows 98, does require the user to confirm the merging to avoid a user mistake.
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 the
SubInACL.exe tool. For example, the permissions on the HKEY_LOCAL_MACHINE\SOFTWARE key can be displayed using:
subinacl /keyreg HKEY_LOCAL_MACHINE\SOFTWARE /display
Programs or scripts
The registry can be edited through the APIs of the Advanced Windows 32 Base API Library (advapi32.dll).
|List of Registry API functions
Many programming languages offer built-in runtime library functions or classes that enable programs to store settings in the registry (e.g.
Microsoft.Win32.Registry in VB.NET and C#, or
TRegistry in Delphi). 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.
The Registry is stored in several files; 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 user-specific HKEY_CURRENT_USER user registry hive is stored in
Ntuser.dat. 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.
Windows NT-based operating systems
Windows NT-based systems store the registry in a binary hive format which is the same format that can be exported, loaded and unloaded by the Registry Editor in these operating systems. The following Registry files are stored in
Userdiff– Not associated with a hive. Used only when upgrading operating systems.
The following files are stored in each user's profile folder:
%UserProfile%\Ntuser.dat– HKEY_USERS\<User SID> (linked to by HKEY_CURRENT_USER)
%UserProfile%\Local Settings\Application Data\Microsoft\Windows\Usrclass.dat(path is localized) – HKEY_USERS\<User SID>_Classes (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. 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
%Windir%\Repair folder contains a copy of the system's registry hives that were created after installation and the first successful startup of Windows.
Windows 95, 98, and Me
The registry files are named
SYSTEM.DAT are stored in the
%WINDIR% directory. In Windows Me,
Classes.dat was added. Also, each user profile (if profiles are enabled) has its own
USER.DAT in profile's directory.
The registry file is
system.dat and is stored in the
C:\WINDOWS directory. These files also contain system registry info:
user.dat and is stored in the
Backups and recovery
Windows supports several methods to back up and restore the registry:
- Windows NT-based operating systems automatically create a backup of each hive (.BAK) in the
%Windir%\System32\configfolder. Any file can be restored from the Recovery Console.
- System Restore can back up the registry and restore it as long as Windows is bootable, or from the Windows Recovery Environment starting with Windows Vista.
- NTBackup can back up the registry as part of the System State and restore it.
- On Windows NT-based systems, the Last Known Good Configuration option in startup menu relinks the
HKLM\SYSTEM\CurrentControlSetkey, which stores hardware and device driver information.
- Windows 98 and Windows Me include command line (Scanreg.exe) and GUI (Scanregw.exe) registry checker tools to check and fix the integrity of the registry, create up to five automatic regular backups by default and restore them manually or whenever corruption is detected. The registry checker tool backs up the registry, by default, to
%Windir%\SysbckupScanreg.exe can also run from MS-DOS.
- The Windows 95 CD-ROM included an Emergency Recovery Utility (ERU.exe) and a Configuration Backup Tool (Cfgback.exe) to back up and restore the registry. Additionally Windows 95 backs up the registry to the files system.da0 and user.da0 on every successful boot.
With Windows 95, Windows 98, Windows Me and Windows NT, administrators can use a special file to be merged into the registry, called a policy file (
POLICY.POL). 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
The policy file filters the settings it enforces by user and by group (a "group" is a defined set of users). 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 NT-based systems.
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.
Windows 2000 and later versions of Windows use Group Policy to enforce Registry settings. Policy may be applied locally to a single computer using
GPEdit.msc, or to multiple computers in a domain using
.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.
Windows Vista has introduced limited Registry virtualization, whereby poorly written applications that write user data to a read-only system location (such as the HKEY_LOCAL_MACHINE hive) can be redirected to a more appropriate location, without changing the application itself. The operation is transparent to the application, as it does not know that its Registry operations have been directed elsewhere.
Similarly, application virtualization redirects all of an application's Registry operations to a non-Registry backed location, such as a file. Used together with file virtualization, this approach allows applications to run without being installed on the location machine.
Lastly, 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 limited users.
Windows 9x operating systems
On Windows 9x computers, an older installation can have a very large registry that slows down the computer's startup and can make the computer unstable. This has led to frequent criticisms that the registry leads to instability. However, as the on-disc structure of the registry is entirely different on the NT line of Operating Systems (including Windows XP and Vista) than Windows 9x series OS, slowdown due to registry bloat now occurs much less frequently.
Equivalents in other operating systems
In contrast to the 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.
Under Unix-like operating systems that follow the Filesystem Hierarchy Standard, system-wide configuration files (information similar to what would appear in HKEY_LOCAL_MACHINE on Windows) are traditionally stored in files in
/etc/ and its subdirectories, or sometimes in
/usr/local/etc. Per-user information (information that would be roughly equivalent to that in HKEY_CURRENT_USER) is stored in hidden directories and files (that start with a period) within the user's home directory. However XDG-compliant applications should refer to the environment variables defined in the Base Directory specification.
Applications running on Apple Inc.'s Mac OS X operating system typically store settings in property list files which are usually stored in each user's Library folder.
RISC OS also allows applications to be copied into directories easily, as opposed to the separate installation program that typifies Windows applications. If one wishes to remove the application, it is possible to simply delete the folder belonging to the application. This will often not remove configuration settings which are stored independently from the application, usually within the computer's !Boot structure, in !Boot.Choices, but potentially anywhere on a network fileserver.
IBM AIX (a Unix variant) uses a registry component called Object Data Manager (ODM). The ODM is used to store information about system and device configuration. An extensive set of tools and utilities provides users with means of extending, checking, correcting the ODM database. The ODM stores its information in several files, default location is /etc/objrepos.
The GNOME desktop environment uses a registry-like interface called GConf for storing configuration settings for the desktop and applications. However, in GConf, all application settings are stored in separate files, thereby eliminating a single point of failure.
The Elektra Initiative provides an alternative back-end for text configuration files for the Linux operating system, similar to the registry.
Advantages and disadvantages
| This article's section called "Advantages and disadvantages" needs additional citations for verification.
Please help improve this article by adding reliable references. Unsourced material may be challenged and removed. (April 2008)
The Windows centralized Registry has a number of advantages over legacy INI files:
- Strongly-typed data can be stored in the Registry, as opposed to only textual information in INI files.
- Separation of machine configuration from user configuration. When a user logs into a Windows NT/2000/XP/Server 2003 computer, the user-based registry settings are loaded from a user-specific path rather than from a read-only system location. This allows multiple users to share the same machine, and also allows programs to work for a least-privilege user.
- Group Policy allows administrators on a Windows-based computer network to centrally manage program and policy settings. Part of this involves being able to set what an entry in the registry will be for all the computers on the network, and affect nearly any installed program — something almost impossible with per-program configuration files each with custom layouts, stored in dispersed locations.
- Standardization of the method of storing configuration data across diverse applications.
- 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.
- The entire registry can be backed up more easily as it is just a small number of files in specific locations. However, it is much harder to back up and restore configuration of a specific application.
- Since accessing the registry does not require parsing, it can be read from and written to more quickly than a text file can be. However, the registry becomes a large file to process once per boot.
- Portions of settings like any subset of an application configuration can be saved in a text-based .
REGfile, which can be edited with any text editor later. .
REGfiles can easily be merged back into the registry both by unattended batch file or by the user just double-clicking on the file without harming any setting that is not explicitly stated in the .
REGfile. This is very useful for administrators and support personnel who want to pre-set or pre-configure only a few options like approving the EULA of a certain application.
- The registry is constructed as a database, and offers DB-like 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, so one will only last a short time until the second gets written. With changes in a file system, such race conditions can result in interleaved data that doesn't match either attempted update. Windows Vista provides transactional updates to the registry, so the atomicity guarantees can be extended across multiple key and/or value changes, with traditional commit-abort semantics. (Note that NTFS provides such support for the file system as well, so the same guarantees could be obtained with traditional configuration files.)
However, the centralized Registry introduces some problems as well:
- Centralizing configurations makes it difficult to back up and recover individual applications.
- In practice, manual manipulation of the registry might be required where applications that are using the Registry do not implement configuration through their user interface.
- Because the Registry structure is contained in binary files, damage to it is difficult to repair. In some cases, a damaged registry may even prevent a Windows system from booting successfully.
- Any application that does not uninstall properly, or does not have an uninstaller, can leave entries in the registry. Over time the computer suffers "software rot" as the registry fills with left-over and possibly incorrect entries.
- Installers and uninstallers become complex, much more than just copying files into a folder.
- Applications that make use of the registry to store and retrieve their settings are unsuitable for use on portable devices used to carry applications from one system to another.
- With a large amount of data stored in a configuration the speed of creating such a config in registry (install) becomes an issue.
- Since an application's configuration is centralized away from the application itself, it is often not possible to copy installed applications that use the Registry to another computer. This means that software usually has to be reinstalled from original media on a computer upgrade or rebuild, rather than just copying the user and software folder to the new computer.
- Registry cleaner
- Application virtualization
- 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.
- "Windows 2000 Registry: Latest Features and APIs Provide the Power to Customize and Extend Your Apps". http://msdn.microsoft.com/msdnmag/issues/1100/Registry/. Retrieved 2007-07-19.
- Chen, R. The Old New Thing, Addison-Wesley, 2007, p. 322.
- "Registry hives". http://msdn2.microsoft.com/en-us/library/ms724877.aspx. Retrieved 2007-07-19.
- Why is a registry file called a "hive"?
- "Designed for Windows XP Application Specification". 2002-08-20. http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=209e3d65-f0be-4eef-8602-73bb9bc29d54. Retrieved 2009-04-08.
- "Description of the Microsoft Windows registry". http://support.microsoft.com/kb/256986. Retrieved 2008-09-25.
- "HKEY_CURRENT_USER". 2009. http://technet.microsoft.com/en-us/library/cc976337.aspx. Retrieved 2009-04-08.
- "HKEY_LOCAL_MACHINE". 2009. http://technet.microsoft.com/en-us/library/cc959046.aspx. Retrieved 2009-04-08.
- Description of the HKEY_DYN_DATA Registry Key in Windows 95, Windows 98, and Windows 98 SE
- A Closer Look at HKEY_DYN_DATA
- Registry linking utility and usage
- Using Registry Editor in Real Mode
- Microsoft's Windows 2000 Security Hardening Guide version 1.3, published May 15, 2003
- Registry Editor Usermanual/docs
- How to add, modify, or delete registry subkeys and values by using a registration entries (.reg) file
- "Reading and Writing Registry Values with Visual Basic". http://www.windowsdevcenter.com/lpt/a/5016. Retrieved 2007-07-19.
- "REG command in Windows XP". http://www.petri.co.il/reg_command_in_windows_xp.htm. Retrieved 2007-07-19.
- Microsoft Corporation
- "Inside the Registry". http://www.microsoft.com/technet/archive/winntas/tips/winntmag/inreg.mspx?mfr=true. Retrieved 2007-12-28.
- "Chapter 26 - Initialization Files and the Registry". http://www.microsoft.com/technet/archive/ntwrkstn/reskit/26_ini.mspx?mfr=true. Retrieved 2008-03-03.
- "Microsoft Application Compatibility Toolkit 5.0". http://technet.microsoft.com/en-us/appcompat/aa905102.aspx. Retrieved 2008-07-26.
- "XDG Base Directory Specification". http://standards.freedesktop.org/basedir-spec/latest/index.html.
- "RISC OS tour". http://www.riscos.org/tour/index.html. Retrieved 2007-07-19.
- "Windows 95 Architecture Components". http://www.microsoft.com/technet/archive/win95/rk31_arc.mspx?mfr=true. Retrieved 2008-04-29.
|Wikibooks has a book on the topic of
- Windows Registry info & reference in the MSDN Library
- Security Accounts Manager - low-level registry and SAM information
- Was the Windows Registry a good idea? at CodingHorror
- REGLN Utility - Create or delete symbolic links in the Windows Registry
- Offline NT Password & Registry Editor - open-source program and boot disk to reset/change windows passwords and edit windows registries under Linux