|Current version||Windows 10|
|License||EULA ( proprietary )|
The Windows registry database (usually just called the registry ) has been the central hierarchical configuration database of the Windows operating system since the first version of Windows NT . Information about Windows itself as well as about programs is saved here.
With Microsoft Windows 3.1 , the Windows registry was also introduced in the consumer operating system sector in 1992 . While file extensions were mainly stored in the registry under the early Windows systems , since Windows NT 3.1 and Windows 95 it has been a comprehensive database for storing all settings for the administration of the system and all integrated system services and processes . Application programs can also save their settings there.
The symbol of the registration database is a large cube composed of many smaller cubes with three free-floating sub-cubes.
Motivation and development history
Before the registry concept became established in Windows, settings in configuration files (e.g. INI files ) were saved separately for each individual program in its directory. However, this has some disadvantages: The entries are saved and evaluated in a text format, which means that they can be easily edited with a text editor , but must first be parsed for further use in programs . This brought performance disadvantages in the 1990s. Furthermore, permissions can only be set at the file level, not at the entry level; Different authorization levels for individual entries can otherwise - where necessary - only be represented by different configuration files.
The registration database does not have these disadvantages: It is saved in a binary format so that its contents can be further processed directly without conversion. Information that is available as long text in a configuration file is "broken up" in the registration database and saved in individual entries. In this way, not only can authorizations be set at entry level, but a blockage caused by simultaneous write access to two programs is avoided if they process different entries. In a configuration file, both would have to open and edit the same file; in the registry, both value pairs are only logically linked by list cells. In order not to have any physical disadvantage when accessing the data due to the "fragmentation", the system has been taking care of defragmentation since Windows XP .
The registry also has advantages in the network using the directory service Active Directory . Several workstation computers can be controlled centrally and at once via group guidelines , because the registry data can also be accessed via a network, since the paths to the values are standardized: A program does not need to know where a certain file is located; it only addresses the standard API , which reads or writes the registry value in the key.
Microsoft has made a number of improvements since the registry was introduced. Up to version NT 5.2 ( Microsoft Windows Server 2003 ) the start-up process of the computer could fail if the kernel and the Hive SYSTEM did not fit in the first 16 MB RAM. With the introduction of Vista, the limitation disappeared. The Kernel Transaction Manager was also introduced with Windows Vista , with which atomic operations within the registry can be implemented, see section Failure safety . With Windows 7, the registry has been improved with regard to the locking behavior: Previously, when accessing a subkey, some upper keys of the path may also be locked; With Windows 7, only the key that is actually accessed is blocked.
Disadvantages of the registry
In addition to the advantages mentioned, the Windows registry also has some significant disadvantages due to its architecture:
The centralized and hierarchical structure can easily lead to a single point of failure if hierarchically higher-level keys are incorrect. Settings that have no or a flat hierarchical structure, such as configuration files, usually still work if individual values are incorrect or individual file names are incorrect.
Applications that save their settings in the registry are often tied to the local computer, which means that migrating from one computer to another very often requires a complete reinstallation of the program. The migration or central storage of settings on a server with the Windows registry is only possible with a great deal of additional effort and special software through synchronization . Configuration files, on the other hand, can be written directly to an integrated server without any detours.
Viewing and editing the settings in the registry requires special software. Configuration files, on the other hand, can be accessed with any simple text editor. Depending on the task, this can minimize the maintenance effort.
Overview and terminology
The registry consists of keys (English keys ) and entries (English entries ). A key is a container for entries and other subkeys , similar to a folder at file level . The graphic opposite shows a selection of important keys in today's registry, arranged in a tree structure. A registry entry is a name-value pair, similar to a file . The value (English value ) of an entry may have different data types, such as binary code, number, or text. Sometimes the term “value” also refers to the name-value pair. The actual values are then referred to as "data". Entries in the registry can also be unnamed, so each key in the registry can accommodate an unnamed entry. These are known as standard values.
The registration database is divided into several main or root keys. The following main keys are available in current Windows versions:
- HKEY_CLASSES_ROOT contains information about supported file types of the computer and the associated file extensions . In most Windows versions, the root key is not real, but only a reflection on
HKEY_LOCAL_MACHINE\Software\Classesor, since Windows 2000, a combination of this key and
HKEY_CURRENT_USER\Software\Classes. This was only saved in a separate file in Windows ME .
- HKEY_CURRENT_USER is a mirror of
HKEY_USERS\<Benutzer-SID>, where is
<Benutzer-SID>the SID of the user currently logged on to the system.
- HKEY_LOCAL_MACHINE saves settings that affect all user accounts logged on to the system.
- HKEY_USERS contains the keys for the individual user accounts. There is a separate subkey for each user, named after the SID of the respective user account. These subkeys are collection points for all settings that only apply to the respective user account.
- HKEY_CURRENT_CONFIG is a reflection on
In addition, the following master keys existed in earlier Windows versions:
- HKEY_DYN_DATA was used to store Plug & Play devices under Windows 9x .
- HKEY_PERFORMANCE_DATA was a root key under Windows NT and was used there to store performance data.
The master keys are often written in abbreviated form, e.g. B. "HKLM" for HK EY_ L OCAL_ M ACHINE or "HKU" for HK EY_ U SERS. The abbreviation HKEY stands for " handle (to a) key ".
Values and data types
Each value can have a theoretical size of 1024 kB, but most values are significantly smaller and only consist of a few bits. The following data types are possible for Windows Vista and higher:
- REG_BINARY: Raw binary code that can be processed without formatting or conversion. The data can either be viewed directly in binary (zeros and ones) or with a hex editor .
- REG_DWORD: A binary data type in which 32-bit integer values are stored as 4-byte hexadecimal values . Used for incremental values, 4-byte status codes or Boolean variables (0 = false, 1 = true).
- REG_QWORD: A binary data type in which 64-bit integer values are stored as 8-byte hexadecimal values . Is used like DWORD, only for larger values.
- REG_SZ: A string of Unicode characters . For names, descriptions, system paths, etc.
- REG_EXPAND_SZ: A character string of variable length that contains environment variables such as% systemroot%, which are expanded during read access.
- REG_MULTI_SZ: Multi-parameter string, the individual elements of which are separated by standard separators so that they can be picked individually from the cell.
- REG_FULL_RESOURCE_DESCRIPTOR: A value that contains an encoded description of the hardware resource, e.g. B. a drive, chipset, etc.
Registry files (hives)
The registration database is saved over several files that are stored in various directories on the computer. Thus, the registry is divided into several sections, which are also known as hives (English for beehives ). A hive is not necessarily identical to a root key. There are root keys that consist of several individual hives (e.g.
HKEY_LOCAL_MACHINEin Windows NT), and root keys can also only be virtual, i.e. represent a link to another part of the registration database.
The distribution and storage location of the files differ depending on the operating system version.
There are the following hives in Windows 9x :
||% systemroot% \ Classes.dat (Windows ME only)||In Windows 95 and 98 this key is a link to
||% systemroot% \ Profile \% username% \ User.dat||Saves user settings.|
||% systemroot% \ System.dat||Saves system settings.|
||random access memory||Stores information about devices connected to the system .|
||% systemdrive% \ Users \% username% \ NTUSER.DAT||Contains settings for Windows and application programs that only affect the respective user account. The
||\ Device \ HarddiskVolume1 \ Boot \ BCD||This is the Boot Configuration Database (BCD), which has existed since Windows Vista. It contains configuration data that are required for the boot loader .|
||% systemroot% \ System32 \ config \ COMPONENTS||Information about the status of Windows features and updates is stored here. For efficiency reasons, this hive is only loaded into the registry when needed. This hive is part of the Component Based Servicing (CBS) architecture introduced with Windows Vista .|
||random access memory||Contains information about hardware connected to the system , such as input devices and the ACPI . This hive is not saved to a file; instead, the required information is read out again each time the computer is started and stored in the main memory. Not all hardware components are listed here. In newer systems, the key is mainly
||% systemroot% \ System32 \ config \ SAM||Database that contains user information such as login name and password. See also: Security Accounts Manager .|
||% systemroot% \ System32 \ config \ SECURITY||Saves the system-wide security guidelines and user rights .|
||% systemroot% \ System32 \ config \ SOFTWARE||System-wide Windows settings that are not required for booting as well as settings of the application programs are stored under this hive .|
||% systemroot% \ System32 \ config \ SYSTEM||Contains Windows settings that are required during the boot process. This includes the settings and status of the drivers and system services .|
||% systemroot% \ System32 \ config \ .DEFAULT||It is the hive of the user account "Local System" ( Local System ) which is used for some system services and processes. This hive is integrated twice; the keys
||% SystemRoot% \ ServiceProfiles \ LocalService \ Ntuser.dat||Hive of the user account "local service" ( Local Service ).|
||% SystemRoot% \ ServiceProfiles \ NetworkService \ Ntuser.dat||Hive of the " Network Service " user account .|
How the registry works
The registry is divided into several files as shown above. “The registry” as a monolithic object and single point of failure therefore does not exist in the strict sense (depending on the damaged file, however, this can still be viewed in this way, e.g. with SYSTEM.DAT). What is represented as a monolithic database with the registry editor regedit.exe, for example, is the implementation of the Configuration Manager, which is part of the NT kernel. The registry is made up of individual files, some of which are listed above, called hives . Each of these hives contains a registry tree, with the first key in the file being the root of the tree. As mentioned above, not all registry trees are real; i.e., they do not have a root directory. Some are just reflections or volatile. If SYSTEM.DAT is loaded into the main memory during the boot phase, the Configuration Manager looks under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hivelistfor the hives' berths. On an example computer:
\REGISTRY\MACHINE\BCD00000000 REG_SZ \Device\HarddiskVolume1\Boot\BCD \REGISTRY\MACHINE\HARDWARE REG_SZ \REGISTRY\MACHINE\SAM REG_SZ \Device\HarddiskVolume2\Windows\System32\config\SAM \REGISTRY\MACHINE\SECURITY REG_SZ \Device\HarddiskVolume2\Windows\System32\config\SECURITY und so weiter...
As can be seen, there are no drive letters for the NT kernel; the root directory begins with "\". The Configuration Manager now creates symbolic links , for example from
\Device\HarddiskVolume2\Windows\System32\config\SECURITY. This is necessary because the Object Manager of the kernel when parsing the string
\REGISTRY\to the handle passes to the Configuration Manager. The registry is addressed like a device.
The Configuration Manager divides each hive into data blocks of 4096 bytes each, as is the case with a hard drive . The hive can only be enlarged or reduced in blocks, i.e. in steps of ± 4kB. The first block of a hive is the basic block, which contains the signature "regf", sequence numbers, time stamp of the last write access in the hive, the version number of the hive, a checksum and its full name (e.g.% SystemRoot% \ CONFIG \ SAM) . The registry data are stored in cells, which can contain key, value, security descriptor, a list of subkeys or key values. A field at the beginning of the cell describes the type and size. If a new cell is placed in the hive and the hive needs to be expanded (+4096 bytes), a container (bin) is created that contains the cell and the empty space of the block. The space between the end of the cell and the end of the container can later be filled with additional cells. Containers (bins) also have a header that contains the signature "hbin" as well as the offset from the beginning of the container / cell to the space behind the cell and the size of the container.
The division of the registry into containers (bin) and cells (cell) enables efficient operation: Since containers are reassigned less frequently than cells, the Configuration Manager can decide to load the containers into the main memory instead of the cells in order to determine the number of ( Un) charging processes. When reading in, the Configuration Manager can also decide to only load containers that contain keys into the main memory and to ignore the empty containers. When a cell is added or removed, the contents of the containers fragment over time, much like a drive. The Configuration Manager therefore continuously defragments the registry itself: When a container becomes empty, the empty containers are placed in sections that are as connected as possible. It also brings together cells that have been fragmented by deletions.
Cells and values are found by jumping: A key cell contains a cell index that contains pointers (computer science) to subkey cells. In order to find the subkeys, the cells also contain a list of the subkeys that are linked to the respective cell index. To speed up the search, the Configuration Manager sorts the lists alphabetically. The lists are jumped through by binary search for the target value: The Configuration Manager first jumps to the middle of the list, then checks whether the value comes before or after the target value in the alphabet, and then jumps to the middle of the upper or lower half. The halving continues until the target value is found. Then the cell index of the target is read out and this cell is jumped to. The process is repeated until the target cell is found or the target does not appear in the list of subkeys. In this case an error message is returned. The following graphic illustrates the jumps from cell to cell in a registry hive in order to read out values (Val 1, Val 2) or subkeys (root, Sub Key).
There are five different types of cells; For the sake of simplicity, the safety description cell is not shown in the graphic. The Configuration Manager first jumps to the basic block and then jumps to the root key. From this key he jumps to a value list cell (light blue), which lets him jump to the value cells Val 1 and Val 2. On the other hand, a subkey list cell (dark blue) is jumped to from the root key, which allows it to jump to the next subkey. The five different types of cells are:
- The key cells, which are displayed in regedit.exe in the left side of the window as a tree structure. They have the signature kn for key or kl if they are only a symbolic link to a key. A time stamp of the last update, a cell index of the upper and lower cells, and an index to the security descriptor cell and the name of the key (e.g. CurrentControlSet) are stored in these key cells.
- The value cells contain the values of the key, which are displayed in regedit.exe on the right side of the window. The signature of the cell is kv, it also contains the type (REG_DWORD, REG_BINARY) and name of the value (e.g. debugger).
- Subkey-list cells contain a list of the subkeys of a key, with their cell index.
- Value-list cells contain a list of the values of their key and their cell index.
- Security descriptor cells contain the access control list and other security-relevant settings of a key. The signature is ks. Several nodes can share a safety description cell, which is why they also contain a list of the nodes.
The Configuration Manager does not access the hard disk image of the hive every time it searches. Instead, all necessary hives are included in the kernel address space by loading them into the swap memory (pagefile.sys). The system hive is only completely loaded into the main memory during booting. Due to the fragmentation in the swap memory , the Configuration Manager operates cell index mapping , which corresponds to virtual memory management , only for the registry cells. It also divides each hive in the swap memory into blocks of 512 bytes and assigns one bit to each. If this section is modified, the bit is turned from 0 to 1 and the section is released for synchronization. The hive sync takes place 5 seconds after the event and synchronizes all changed hive sections between the swap memory and the image. If further modifications are made to the hives in the meantime or afterwards, these are only synchronized after a further 5 seconds. In order to ensure that a recovery is possible even after the computer has been smeared down during synchronization, the changed sections are first written to the * .log files, which are available alongside all Hive files. Then the Configuration Manager increases a consecutive number in the hive, writes the modified section of the * .log to the Hive file * .DAT and increases a second consecutive number in the hive. If the computer crashes during the write process, the Configuration Manager sees after the reboot that the consecutive numbers do not match and continues to update from * .log to * .DAT.
In the past, each file in the machine hive and the .DEFAULT.DAT had a * .sav and * .log as redundancy, whereby SYSTEM.DAT also had SYSTEM.old as redundancy. Only NTUSER.DAT was limited to a * .log. This was retained up to and including Windows Vista . Modern NT systems from Windows 7 onwards have * .log, * .log1, * .log2 as redundancy for every registry file, not just SYSTEM.DAT.
The Configuration Manager creates a Key Control Block (KCB) for each opened registry key . This contains the complete path of the key, a cell index of the node and a flag as to whether the key control block should be deleted when the last handle has ended. Windows stores all key control blocks in an alphabetically ordered hash table for faster access. When an application
\REGISTRY\Namenspfadparses the kernel's Object Manager , it passes the name path to the Configuration Manager. This jumps through the keys and subkeys as described above until the target key (target cell) is found. The Configuration Manager then checks whether the key has already been opened. If so, the counter in the key control block is increased by 1. If not, Configuration Manager creates another key control block and adds it to the hash table. It then creates a key object that points to the key control block and passes it to the Object Manager, which forwards it to the application. If another application wants to access the same key, it will also see the key object. If a new key is to be created, the Configuration Manager first jumps to the last existing key in the jump chain. Then it checks whether the space in the list of free cells is sufficient to accommodate the new key. If not, a new container is opened. Otherwise the new key with all data is created and entered in the index list of the father key.
Up to Windows NT 6.1 there was only one global hash table for all KCBs. Starting with Windows 7, each hive has its own hash table; Furthermore, the access to keys has been improved: In the case of write access to a subkey, all upper keys of the path were previously locked; this only affects the key that is actually written to. The synchronization cycle has also been increased.
Storage of application settings
User programs can store their own information in the registry.
Applications do not need to use the Windows registry. For example, NET Framework applications use XML files for configuration, while portable applications usually store their configuration files with their executable files. Applications that are platform independent , such as B. Firefox or VLC save your settings in configuration files that are specially designed for your needs. Many applications use the Windows registry sparingly in order to be independent of interfaces that are only available in Windows.
It is up to the program manufacturer whether this information is to be stored in the registration database or in one of the shared folders listed below (status: Windows 10):
%programdata%is the directory of the data that affect all users (on Windows 10 systems:)
C:\ProgramData. Administrator rights are required to create folders and files there. Therefore, these are created by the installation program of the user program, the corresponding folders can be configured in such a way that programs that run under the user context also have write access to them.
%userprofile%\AppData\Roaming: The folders stored here move with the user when he logs on to another computer in the domain.
%userprofile%\AppData\Local: The settings stored there are linked to the computer.
%userprofile%\AppData\LocalLowis a sandbox directory with a low commitment level.
Manual editing options
In order to edit the registry database manually, Windows provides the registry editor regedit.exe . This can be called up in the search bar by entering regedit . In the left column the hives and key cells are shown hierarchically, on the right the associated value cells of a key and their content are listed individually. The key list cells are not displayed, only abstracted by the tree structure of the keys. The value list cells are also not visible, but form the structure of the list on the right. The security descriptor cells are abstracted through the context menu when a key > permissions ... right click is executed.
The entire registry can be exported by right-clicking on the "Computer" icon > Export . Parts that are not attached, e.g. B. Schema.DAT and Components.DAT are not taken into account. If a (sub) key is selected and exported, this and its substructures are written to a registration file with the file extension * .reg, which is coded in Unicode and can therefore be read by humans. If a key is selected and File> Print ... is selected in the window menu , the information of the key cells that is not displayed in the registry editor but is part of the cell (for example the last write access and the class name) is also printed out. The * .reg files are Unicode text files with the character string "Windows Registry Editor Version 5.00" in the first line. The syntax is as follows:
If the default value of a key is to be edited, an at sign is prefixed:
Character strings ("string values") do not require a value type specification. Paths in value cells must be written with "\\", individual "" "as" \ "". There are the following hex () abbreviations for the value type:
Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Wikipedia] "PathToExe"="C:\\Program Files (x86)\\ACME Corp\\ACE.exe" "haenschen"=hex:<Binär-Wert> "klein"=dword:<DWORD-Wert> "geht"=hex(0):<REG_NONE-Wert> "allein"=hex(1):<REG_SZ-Wert> "in"=hex(2):<REG_EXPAND_SZ Wert> "die"=hex(3):<Binär-Wert> ; identisch mit "hex:" "weite"=hex(4):<DWORD-Wert> ; Little-Endian "Welt"=hex(5):<DWORD-Wert> ; Big-Endian "hinein"=hex(7):<REG_MULTI_SZ-Werte> ; getrennt durch Komma "Stock"=hex(8):<REG_RESOURCE_LIST-Werte> ; getrennt durch Komma "und"=hex(a):<REG_RESOURCE_REQUIREMENTS_LIST-Werte> ; getrennt durch Komma "Hut"=hex(b):<QWORD-Wert> ; acht Hex-Werte, getrennt durch Komma
A preceding minus removes the key:
Values in a key are removed by a "-" after the value name:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wikipedia] @=- "MeineMeinung"=-
@=-the default value is removed and
MeineMeinungand its value. Comments can also be included in the reg data:
; Dies ist ein Kommentar. Er fällt vergleichsweise lang aus [HKEY_LOCAL_MACHINE\SOFTWARE\Wikipedia] "MeineMeinung"="WikipediaIstGut"
The reg files are read into the registry when they are double clicked. Editing is possible with a right click> Edit .
Since the appearance of Windows PowerShell, there is another very easy way to manage the registry. You can access the registry directly via the console or through a shell script like a conventional drive. In the "normal" directory you navigate with the aliases
lsto display subdirectories, to navigate
cd <ziel>to a subdirectory, to
cd ..go back one directory, etc. If you enter, for example
cd HKLM:, you switch to the main key HKEY_LOCAL_MACHINE . The sub-keys can also be accessed via the command
cdor in the long form
Set-Location. The command
Get-ItemProperty .shows all properties (registry entries) that are saved for the current registry key. In this way, for example, by entering the following command sequence in PowerShell, all entries of the Run key can be displayed:
cd HKLM: cd Software\Microsoft\Windows\CurrentVersion\Run Get-ItemProperty .
After entering, among other things (PSPath, PSParentPath, PSChildName, PSProvider) is output
PSDrive: HKCU. The same applies if the computer
Get-PSDrive's drives are displayed using the command , although not all registry drives are displayed here. As already shown above in the section “How the registry works”, the registry is managed by Windows itself like a drive / device, which is also visible in PowerShell. With the command
cd C:\or another drive letter, PowerShell switches back to the world of the Object Manager / File Explorer.
Indirect reading of the registry is also possible: With the commands
$key="HKCU:\Software\Microsoft\Windows\CurrentVersion\Run"the path is fetched and written into the variable $ key,
$wert="Test"fetches the value "Test" and puts it into the variable $wert, and with
(Get-ItemProperty $key).$wertthe property "Test" in the key "Run" are output, here the path of the autostart entry.
New-Item HKCU:\Software\Wikipedia(alias: md) creates a new key called "Wikipedia",
Remove-Item HKCU:\Software\Wikipedia(alias: del) removes it again. With
New-ItemProperty -Path HKCU:\SOFTWARE\Wikipedia -Name MeineMeinung -PropertyType String -Value WikipediaIstGuta string named “MeineMeinung” with the value “WikipediaIstGut” is stored in the key “Wikipedia”. In addition to String (REG_SZ), ExpandString (REG_EXPAND_SZ), Binary (REG_BINARY), DWord (REG_DWORD), MultiString (REG_MULTI_SZ) and QWord (REG_QWORD) are also permitted.
Console registration program
The console registration program reg.exe only runs within a command prompt cmd.exe, whereby the commands can also be used in PowerShell. The syntax is very simple, but the disadvantage is the lack of command line extensions , which increases the risk of typing errors. The syntax for querying keys is as follows:,
REG QUERY Schlüssel(pfad)with the optional parameters attached, / v value (searches for a specific registry value), / ve (searches for the default or empty value), and / s (searches for all subkeys and values ). The command
reg query HKCU\Software\Microsoft\Windows\Currentversion\run
Entered in a cmd.exe returns a list of all autostart entries of the Run key in the user hive. The syntax for creating keys is as follows:
REG ADD Schlüsselwith the attached optional parameters / v value (value to be added under the key), / ve (adds a standard value), / t (data types: REG_SZ | REG_MULTI_SZ | REG_DWORD_BIG_ENDIAN | REG_DWORD | REG_BINARY | REG_DWORD_LITTLE_ENDIAN | REG_NONE | REG_EXPAND_SZ), / s (specifies the separator in the data string), / d (data), and / f (overwrite). The command
reg add HKCU\Software\Microsoft\Windows\Currentversion\run /v Test /t REG_SZ /d calc.exe
creates the character string (REG_SZ) named "Test" in the "Run" key, which has the value "calc.exe". If this key were retained, the calculator would pop up immediately after the user logs in. The syntax for removing keys is as follows:
REG delete Schlüsselwith the appended optional parameters / v value (value to be deleted under the key), / ve (deletes the value of the default value), / va (deletes all entries of the key), and / f (for “by force”). The command
reg delete HKCU\Software\Microsoft\Windows\Currentversion\run /v Test
deletes the string "Test" with its value "calc.exe". The evil calculator is banned. The command
REG COPY Schlüssel1 Schlüssel2copies key 1 to the position of key 2. With the parameter / s the complete subkeys are taken, / f forces copying. Further commands such as Save, Load, Unload, Restore, Compare, Export, Import etc. etc. are possible.
Due to the fact that large parts of the system configuration are stored in the registry, this is often viewed as a single point of failure . Damage to the registry can make it difficult or even impossible to start the operating system. As a result, a number of measures are taken that can prevent or reverse damage to the registry database:
- With the Kernel Transaction Manager introduced in Windows Vista , several individual operations can be combined into one transaction , which either runs successfully as a whole or can be reversed by means of a rollback , which is intended to prevent inconsistent states.
- Protection against inconsistent states is also guaranteed by the implementation of the registry itself, since changes to the registry are recorded in log files . If a write process is unexpectedly aborted (e.g. due to a power failure) after some of the data has already been changed, these changes can be reversed.
- The file system in which the registry files are stored can also counteract damage. So has NTFS , the modern in all versions of Windows is used, extensive error checking and repair mechanisms.
- The particularly sensitive section SYSTEM was saved as a backup in the SYSTEM.ALT file in earlier versions of Windows .
It is often advertised that a “cleaning” of the registration database is necessary or desirable in order to obtain a speed and stability advantage.
The benefits of so-called "registry cleaners" are, however, mostly doubted and classified as a myth . Unused and thus superfluous entries in the registry would only make up a negligibly small part, the cleaning of which is of no consequence. The US-American author and Most Valuable Professional Ed Bott rates the benefit as negligible and at the same time warns that an incorrectly removed entry could lead to programs installed on the system no longer working properly. The use of registry cleaners should therefore be rejected: “Don't run registry cleaner programs, period.” (German: “Do not use any programs to clean up the registry. Period.”).
The supposed benefit of cleaning up the registry could not be proven in test reports either: The Windows Secrets website tested the cleaning programs CCleaner and jv16 PowerTools 2011 and compared them with Windows internal disk cleaning . Neither program could measure any speed advantage over Windows disk cleanup. Windows Disk Cleanup leaves the registry untouched and is limited to deleting unnecessary files on the hard drive.
Up to Windows XP (including Windows Server 2003), the boot process could fail if the kernel and SYSTEM.DAT occupied more than the first 16 MB of RAM. Microsoft therefore offered its in-house tool "RegClean" to remove unnecessary registry entries. However, this is superfluous with all modern Windows versions.
Back up the registry
Windows 95 saves the registry each time it starts up successfully and saves it as
USER.DA0in the system directory. A manual backup is
ERU.EXEpossible with the program on the Windows 95 CD.
Under Windows 98 and Windows Me there is a program instead
SCANREG.EXEthat saves numerous important system files, including the registry, every time Windows is successfully started, but can also be called up manually to create a backup or to restore the system from a backup. By default, up to five backups are created as CAB files in the% systemroot% \ Sysbckup folder. These and other settings can be modified via an INI file. Due to a program error,
USER.DATdoes not save if it is not in the system directory because several user profiles have been created.
All versions of Windows 9x also offer the option of using the registry editor
REGEDIT.EXEin MS-DOS mode to export and re-import the entire registry into a registry file . Windows 9x also backs up a copy of the
SYSTEM.DATunder the name
SYSTEM.1STin the root directory of the hard disk immediately after the Windows setup .
Windows NT up to and including version 4.0 offered the option of creating a copy of the registry in the% systemroot% \ repair directory and, if necessary, backing it up on a so-called emergency disk. Windows creates such an emergency floppy disk by default at the end of the setup, but a backup copy of the registry and (optionally) an emergency floppy disk can also be created manually by calling the program
RDISK.EXE. By default, the files
SECURITYnot backed up, unless
RDISK.EXEthe / S parameter is used .
In Windows 2000 and Windows XP, the registry is instead backed up using the Backup (
NTBACKUP.EXE) program . The Backup program is not available as standard in Windows XP Home Edition , but it can be installed from the Windows XP CD.
Operating systems from Windows Vista upwards no longer offer the possibility to save the registry.
Windows registry without Windows
The Win32 API called Wine , which is available for Linux and Unix systems, contains its own implementation of the Windows registry. Wine itself stores its own settings in it. In addition, other Windows programs that run on Wine can enter their settings there. For Win32 applications, the registry appears exactly the same as on a Windows NT system. In the background, however - unlike in Windows NT systems and as is usual for settings in Unix systems - there is no database, but simple ASCII text files. The following files in the directory contain the Wine registration database in the form of readable texts:
|userdef.reg||HKEY_USERS \ .Default|
The ReactOS project, which tries to recreate Windows NT, takes over parts of Wine, including the implementation of the Windows registry database.
However, there are projects that want to provide registry-like databases for Unixoid systems, for example Elektra or the Gnome configuration database GConf or its successor DConf . In contrast to the Windows registry and DConf, GConf was consistently based on XML files, which offered the possibility of reading and editing the keys with any text editor or XML parser . Elektra also stores the keys in plain text files, which are e.g. B. can be edited with editors like vi .
- Registry Microsoft Developer Network (MSDN) (English)
- Günter Born ( MVP ): Tuning tools, the plague of the 21st century?
- Martin Grotegut: Windows 7 in company networks with Service Pack 1, IPv4, IPv6 . Springer, 2011, ISBN 978-3-642-01034-7 .
- Ingo Böttcher ( MVP ): The best Windows tuning tips ... June 7, 2011, accessed on January 18, 2015 .
- Tools for everything to do with the Windows registry. Computerwoche, May 28, 2013, accessed January 18, 2015 .
- Windows 7 / Windows Server 2008 R2: Upgrade Paths, Registry Enhancements, Crash Dumps and Page File Sizing. Microsoft TechNet, October 1, 2009, accessed January 18, 2015 .
- Registry Keys. In: Microsoft Developer Network . August 4, 2010, accessed December 3, 2015 .
- Mark Russinovich, David Solomon, Alex Ionescu: Windows Internals, Part 1 . Microsoft Press, 2012, ISBN 978-0-7356-4873-9 , pp. 277 ff .
- Why do registry keys have a default value? In: The New Old Thing. Microsoft , January 18, 2008, accessed December 3, 2015 .
- Windows registry information for advanced users. Microsoft Support, May 6, 2013, accessed February 11, 2015 .
- Total Registry - Infoguide all about the registry. In: WinTotal.de. June 20, 2004, accessed November 29, 2015 .
- Christoph Prevezanos: Computer-Lexikon 2012 . Markt + Technik Verlag, 2011, ISBN 978-3-8272-4728-5 , p. 398 ( limited preview in Google Book search).
- Forensic Investigation on Windows Machines. In: INFOSEC institute. Retrieved November 8, 2016 .
- William Stanek: Windows Server 2008 Inside Out . Microsoft Press, 2008, ISBN 978-0-7356-2438-2 .
- Registry Hives (Windows). In: msdn.microsoft.com. Retrieved November 27, 2015 .
- Paul Robichaux: Managing The Windows 2000 Registry . O'Reilly & Associates, 2000, ISBN 1-56592-943-8 .
- Barry Simon: The Windows 95 Registry, Part 1 . In: PC Magazine . Volume 14, No. 8 , 1995, p. 251 ff . ( Preview on Google Books ).
- Appendix A - Windows NT Registry. In: Windows NT 4.0 Server Product Documentation. Microsoft , accessed November 29, 2015 .
- The .Default user is not the default user. In: The Old New Thing. Microsoft , March 2, 2007, accessed November 28, 2015 .
- Known Security IDs in Windows Operating Systems. Microsoft , accessed November 29, 2015 .
- Mark Russinovich: Inside the Registry. Retrieved January 18, 2015 (English, undated).
- Paul McFedries: Microsoft Windows Vista Unleashed . Sams, 2008, ISBN 978-0-672-33013-1 , pp. 299 ff .
- Tarik Soulami: Inside Windows Debugging . Microsoft Press, 2012, ISBN 978-0-7356-6278-0 .
- Alexander Schatten, Stefan Biffl, Markus Demolsky, Erik Gostischa-Franta, Thomas Östreicher and Dietmar Winkler: Best Practice Software Engineering: A tried and tested compilation of component-oriented concepts, methods and tools , Springer-Verlag, ISBN 9783827424877
- Holger Schwichtenberg u. others: Windows Vista Business . Addison-Wesley Verlag, 2007, ISBN 978-3-8273-2422-1 .
- Kernel Transaction Manager (Windows). In: MSDN Library. Accessed December 4, 2015 .
- Mike Halsey, Andrew Bettany: Windows Registry Troubleshooting . Apress, 2015, ISBN 978-1-4842-0992-9 , pp. 33 f . ( Preview on Google Books [accessed December 6, 2015]).
- The Myth Hunter - Episode 22: Cleaning the Registry. In: CHIP Online. December 29, 2012, accessed December 3, 2015 .
- What's the Registry, Should I Clean It, and What's the Point? In: Lifehacker. January 3, 2010, accessed December 3, 2015 .
- Ed Bott : Why I don't use registry cleaners. (No longer available online.) April 19, 2005, archived from the original on December 8, 2015 ; accessed on December 3, 2015 . Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.
- Putting registry / system cleanup apps to the test. Windows Secrets, November 10, 2011, accessed January 18, 2015 .
- System may not start when creating a large number of logical units and volumes. Support Microsoft, accessed January 20, 2015 .
- Microsoft Knowledge Base - Using Registry Editor in Real Mode
- Microsoft Knowledge Base - Windows 95 Emergency Recovery Utility
- Microsoft Knowledge Base - Description of the Windows Registry Checker Tool (Scanreg.exe)
- Microsoft Knowledge Base - How to Customize Registry Checker Tool Settings
- Scanreg.exe Does Not Back Up User.dat Files When Using User Profiles
- Microsoft Knowledge Base - Troubleshooting Windows 95 Using Safe Mode
- Microsoft Knowledge Base - Description of Windows NT Emergency Repair Disk
- RDISK / S and RDISK / S- Options in Windows NT
- Microsoft Knowledge Base - How to Create an Emergency Repair Disk in Windows 2000
- How can I get NTBackup for Windows XP Home Edition?
- Using the Registry and Regedit (English)
- Using ReactOS registry format (English)
- Interview: Elektra, the Linux Registry on golem.de (2004)
- www / Software / Elektra on Freedesktop.org (English)
- Interview: Elektra, the Linux Registry on golem.de (2004)
- The plist (5) manual page on developer.apple.com. Retrieved January 23, 2014.