# Registrierungsdatenbank

Die Windows-Registrierungsdatenbank (meist nur Registry genannt) ist seit der ersten Version von Windows NT die zentrale hierarchische Konfigurationsdatenbank des Betriebssystems Windows. Die Registrierungsdatenbank verwaltet Informationen zum Betriebssystem und zu Anwendungen.
Mit Microsoft Windows 3.1 wurde die Windows-Registry 1992 auch im Bereich der Consumer-Betriebssysteme eingeführt. Während darin unter Windows 3.x hauptsächlich Dateierweiterungen gespeichert wurden, ist sie in Windows NT 3.1 und seit Windows 95 eine umfassende Datenbank zur Speicherung aller Einstellungen für die Verwaltung des Systems und aller integrierten Systemdienste und -prozesse. Anwendungsprogramme können ihre Einstellungen ebenfalls dort speichern.
Das Symbol der Registrierungsdatenbank ist ein aus vielen kleineren Würfeln zusammengesetzter großer Würfel mit drei freischwebenden Teilwürfeln.

## Motivation und Entwicklungsgeschichte

Bevor sich in Windows das Konzept der Registry durchgesetzt hatte, wurden Einstellungen in Konfigurationsdateien (z. B. INI-Dateien) separat für jedes einzelne Programm in dessen Verzeichnis gespeichert. Dies bringt jedoch einige Nachteile mit sich: So werden die Einträge in einem Textformat gespeichert und ausgewertet, wodurch diese zwar einfach mit einem Texteditor bearbeitet werden können, für die Weiterverwendung in Programmen aber erst geparst werden müssen. Dies brachte in den 1990er Jahren Performancenachteile mit sich. Ferner können Berechtigungen, wer Werte einsehen oder bearbeiten kann, nur auf Dateiebene, nicht auf Eintragsebene gesetzt werden; verschiedene Berechtigungsstufen für einzelne Einträge ließen sich sonst – wo nötig – nur durch verschiedene Konfigurationsdateien abbilden.
Die Registrierungsdatenbank hat diese Nachteile nicht: Sie wird in einem binären Format gespeichert, sodass ihre Inhalte direkt und ohne Konvertierung weiterverarbeitet werden können. Informationen, die in einer Konfigurationsdatei als langer Text vorliegen, werden in der Registrierungsdatenbank „zerstückelt“ und in einzelnen Einträgen gespeichert. Dadurch können nicht nur Berechtigungen auf Eintragsebene gesetzt werden, sondern eine Blockade durch gleichzeitigen Schreibzugriff zweier Programme wird vermieden, wenn diese unterschiedliche Einträge bearbeiten. In einer Konfigurationsdatei müssten beide dieselbe Datei öffnen und editieren, in der Registrierung sind beide Wertepaare nur logisch durch Listen-Zellen verbunden. Um durch die „Zerstückelung“ keinen physikalischen Nachteil bei Zugriff auf die Daten zu haben, sorgt das System seit Windows XP von selbst für eine Defragmentierung.
Vorteile bringt die Registry auch im Netzwerkverbund unter Verwendung des Verzeichnisdienstes Active Directory. Über Gruppenrichtlinien können mehrere Arbeitsplatzrechner zentral und auf einmal gesteuert werden, denn auf die Daten der Registry kann auch über ein Netzwerk zugegriffen werden, da die Pfade zu den Werten standardisiert sind: Ein Programm muss nicht wissen, wo eine bestimmte Datei liegt; es spricht nur die Standard-Schnittstelle der Registrierdatenbank an und das Betriebssystem übernimmt die konkreten Lese- oder Schreibzugriffe.
Seit der Einführung der Registrierungsdatenbank wurden von Microsoft eine Reihe von Verbesserungen durchgeführt. Bis zur Version NT 5.2 (Microsoft Windows Server 2003) konnte der Startvorgang des Rechners scheitern, wenn der Kernel und der Hive SYSTEM nicht in die ersten 16 MB Arbeitsspeicher passten. Mit der Einführung von Vista fiel die Beschränkung weg. Ebenfalls mit Windows Vista wurde der Kernel Transaction Manager eingeführt, mit dem sich atomare Operationen innerhalb der Registry realisieren lassen, siehe Abschnitt Ausfallsicherheit. Mit Windows 7 wurde die Registry in Bezug auf das Sperr-Verhalten verbessert: Zuvor wurden bei einem Zugriff auf einen Unterschlüssel möglicherweise einige Oberschlüssel des Pfades mitgesperrt; mit Windows 7 wird nur noch der Schlüssel gesperrt, auf den tatsächlich auch zugegriffen wird.

### Nachteile der Registrierungsdatenbank

Die Windows-Registrierung hat neben den genannten Vorteilen auch einige bedeutende Nachteile, die sich aufgrund ihrer Architektur ergeben:
Die zentralisierte und hierarchische Struktur kann leicht zu einem Single Point of Failure führen, wenn hierarchisch übergeordnete Schlüssel fehlerhaft sind. Einstellungen, die keine oder eine flache hierarchische Struktur, wie Konfigurationsdateien, aufweisen, funktionieren meist auch dann noch, wenn einzelne Werte fehlerhaft oder einzelne Dateinamen falsch sind.
Anwendungen, die ihre Einstellungen in der Registry speichern, sind oft an den lokalen Rechner gebunden, was bedeutet, dass die Migration von einem Computer zum anderen sehr oft eine komplette Neuinstallation des Programms erfordert. Das Migrieren oder zentrale Speichern von Einstellungen auf einem Server ist mit der Windows-Registrierung nur mit großem zusätzlichem Aufwand und spezieller Software durch Synchronisation möglich. Konfigurationsdateien können dagegen direkt und ohne Umweg auf einen eingebundenen Server geschrieben werden.
Das Anzeigen und Bearbeiten der Einstellungen in der Registrierdatenbank benötigt spezielle Software. Konfigurationsdateien sind dagegen mit jedem einfachen Texteditor zugänglich. Dies kann je nach Aufgabe den Wartungsaufwand minimieren.

## Aufbau
### Überblick und Terminologie

Die Registrierungsdatenbank besteht aus Schlüsseln (englisch keys) und Einträgen (englisch entries). Ein Schlüssel ist dabei ein Behälter für Einträge und weitere Unterschlüssel, ähnlich einem Ordner auf Dateiebene. Die nebenstehende Grafik zeigt eine Auswahl wichtiger Schlüssel der heutigen Registry, angeordnet in einer Baumstruktur. Ein Eintrag in der Registrierungsdatenbank ist ein Name-Wert-Paar, ähnlich einer Datei. Der Wert (englisch value) eines Eintrags kann unterschiedliche Datentypen aufweisen, etwa Binärcode, Zahl oder Text. Manchmal wird mit dem Begriff „Wert“ auch das Name-Wert-Paar gemeint. Die eigentlichen Werte werden dann als „Daten“ bezeichnet. Einträge in der Registry können auch unbenannt sein, so kann jeder Schlüssel in der Registry einen unbenannten Eintrag beherbergen. Diese werden als Standard-Werte bezeichnet.

### Hauptschlüssel

Die Registrierungsdatenbank ist in mehrere Haupt- bzw. Wurzelschlüssel unterteilt. Folgende Hauptschlüssel sind in aktuellen Windows-Versionen vorhanden:
* HKEY_CLASSES_ROOT enthält Informationen über unterstützte Dateitypen des Rechners und die dazugehörigen Dateiendungen. Der Wurzelschlüssel ist bei den meisten Windows-Versionen nicht real, sondern nur eine Spiegelung auf HKEY_LOCAL_MACHINE\Software\Classes bzw. seit Windows 2000 eine Kombination aus diesem Schlüssel und HKEY_CURRENT_USER\Software\Classes. Nur in Windows ME war dieser in einer separaten Datei gespeichert.
* HKEY_CURRENT_USER ist eine Spiegelung von HKEY_USERS\<Benutzer-SID>, wobei <Benutzer-SID> die SID des aktuell am System angemeldeten Benutzers ist.
* HKEY_LOCAL_MACHINE speichert Einstellungen, die alle am System angemeldeten Benutzerkonten betreffen.
* HKEY_USERS enthält die Schlüssel der einzelnen Benutzerkonten. Für jeden Benutzer ist dort ein eigener Unterschlüssel angelegt, benannt nach der SID des jeweiligen Benutzerkontos. Diese Unterschlüssel sind Sammelstellen für alle Einstellungen, die nur für das jeweilige Benutzerkonto gelten.
* HKEY_CURRENT_CONFIG ist eine Spiegelung auf HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles\Current.
Daneben gab es in früheren Windows-Versionen zusätzlich die folgenden Hauptschlüssel:
* HKEY_DYN_DATA diente zur Speicherung von Plug-&-Play-Geräten unter Windows 9x.
* HKEY_PERFORMANCE_DATA war ein Wurzelschlüssel unter Windows NT und diente dort zur Speicherung von Leistungsdaten.
Die Hauptschlüssel werden häufig abgekürzt geschrieben, z. B. „HKLM“ für HKEY_LOCAL_MACHINE oder „HKU“ für HKEY_USERS. Die Abkürzung HKEY steht dabei für „handle (to a) key“.

### Werte und Datentypen

Jeder Wert kann eine theoretische Größe von 1024 kB haben, die meisten Werte sind aber deutlich kleiner, und bestehen nur aus wenigen Bits. Es sind folgende Datentypen für Windows Vista und höher möglich:
* REG_BINARY: Roher Binärcode, der ohne Formatierung oder Umwandlung verarbeitet werden kann. Die Daten können entweder direkt binär (Nullen und Einsen) oder mit einem Hex-Editor angesehen werden.
* REG_DWORD: Ein Binärdatentyp, bei dem 32-Bit große Integer-Werte als 4 Byte lange Hexadezimalwerte gespeichert werden. Wird für inkrementelle Werte, 4-Byte-Statuscodes oder boolesche Variablen (0=falsch, 1=wahr) verwendet.
* REG_QWORD: Ein Binärdatentyp, bei dem 64-Bit große Integer-Werte als 8 Byte lange Hexadezimalwerte gespeichert werden. Wird wie DWORD eingesetzt, nur für größere Werte.
* REG_SZ: Eine Zeichenkette aus Unicode-Schriftzeichen. Für Namen, Beschreibungen, Systempfade usw.
* REG_EXPAND_SZ: Eine Zeichenkette variabler Länge, die Umgebungsvariablen wie %systemroot% enthält, die beim Lesezugriff expandiert werden.
* REG_MULTI_SZ: Multi-Parameter-String, dessen einzelne Elemente durch Standard-Trennzeichen abgetrennt werden, sodass diese einzeln aus der Zelle herausgepickt werden können.
* REG_FULL_RESOURCE_DESCRIPTOR: Ein Wert, der eine kodierte Beschreibung der Hardware-Ressource enthält, z. B. eines Laufwerkes, Chipsatzes usw.

### Dateien der Registry (Hives)

Die Registrierungsdatenbank wird über mehrere Dateien verteilt gespeichert, die in verschiedenen Verzeichnissen des Rechners abgelegt sind. Somit wird die Registry in mehrere Teilabschnitte unterteilt, welche auch als Hives (englisch für Bienenstöcke) bezeichnet werden. Ein Hive ist dabei nicht zwangsweise mit einem Wurzelschlüssel identisch. So gibt es Wurzelschlüssel, die aus mehreren einzelnen Hives bestehen (z. B. HKEY_LOCAL_MACHINE bei Windows NT), des Weiteren können Wurzelschlüssel auch nur virtuell sein, also einen Link auf einen anderen Teil der Registrierungsdatenbank darstellen.
Je nach Betriebssystem-Version unterscheiden sich Aufteilung und Speicherort der Dateien.

#### Windows 9x

In Windows 9x gibt es die folgenden Hives:
| Hive | Speicherort | Beschreibung |
| HKEY_CLASSES_ROOT | %systemroot%\Classes.dat (nur Windows ME) | In Windows 95 und 98 ist dieser Schlüssel ein Link auf HKLM\Software\Classes. |
| HKEY_CURRENT_USER | %systemroot%\Profile\%username%\User.dat | Speichert Benutzer-Einstellungen. |
| HKEY_LOCAL_MACHINE | %systemroot%\System.dat | Speichert System-Einstellungen. |
| HKEY_DYN_DATA | Arbeitsspeicher | Speichert Informationen über am System angeschlossene Geräte. |

#### Windows NT

In Betriebssystemen auf Basis des NT-Kernels, bis einschließlich Windows 10, gibt es folgende Hives:
| Hive | Speicherort | Beschreibung |
| HKEY_CURRENT_USER HKU\<Benutzer-SID> | %systemdrive%\Users\%username%\NTUSER.DAT | Enthält Einstellungen für Windows und Anwendungsprogramme, die nur das jeweilige Benutzerkonto betreffen. Unter HKEY_CURRENT_USER wird der Hive des aktuell am System angemeldeten Benutzerkontos eingebunden. |
| HKLM\BCD00000000 | \Device\HarddiskVolume1\Boot\BCD | Dies ist die Boot Configuration Database (BCD), welche seit Windows Vista existiert. Sie enthält Konfigurationsdaten, die für den Bootloader benötigt werden. |
| HKLM\COMPONENTS | %systemroot%\System32\config\COMPONENTS | Hier werden Informationen über den Zustand von Windows-Features und Updates abgelegt. Aus Effizienzgründen wird dieser Hive nur bei Bedarf in die Registrierungsdatenbank geladen. Dieser Hive ist Teil der mit Windows Vista eingeführten Component Based Servicing (CBS)-Architektur. |
| HKLM\HARDWARE | Arbeitsspeicher | Enthält Informationen über am System angeschlossene Hardware, wie Eingabegeräte und das ACPI. Dieser Hive wird nicht in einer Datei gespeichert; stattdessen werden die benötigten Informationen bei jedem Start des Rechners erneut ausgelesen und im Arbeitsspeicher abgelegt. Nicht alle Hardware-Komponenten sind hier gelistet. Bei neueren Systemen wird dazu hauptsächlich der Schlüssel HKLM\SYSTEM\CurrentControlSet\Enum verwendet. |
| HKLM\SAM | %systemroot%\System32\config\SAM | Datenbank, die Benutzerinformationen wie Anmeldename und Kennwort enthält. Siehe auch: Security Accounts Manager. |
| HKLM\SECURITY | %systemroot%\System32\config\SECURITY | Speichert die systemweit gültigen Sicherheitsrichtlinien und Benutzerrechte. |
| HKLM\SOFTWARE | %systemroot%\System32\config\SOFTWARE | Unter diesem Hive werden systemweite Windows-Einstellungen, die nicht zum Booten benötigt werden, sowie Einstellungen der Anwendungsprogramme abgespeichert. |
| HKLM\SYSTEM | %systemroot%\System32\config\SYSTEM | Enthält Windows-Einstellungen, die bereits während des Bootens benötigt werden. Dazu gehören Einstellungen und Zustand der Treiber und Systemdienste. |
| HKU\.DEFAULT HKU\S-1-5-18 | %systemroot%\System32\config\.DEFAULT | Es handelt sich um den Hive des Benutzerkontos „Lokales System“ (Local System), das für einige Systemdienste und -prozesse verwendet wird. Dieser Hive wird zweifach eingebunden; die Schlüssel HKU\.DEFAULT und HKU\S-1-5-18 sind also identisch. |
| HKU\S-1-5-19 | %SystemRoot%\ServiceProfiles\LocalService\Ntuser.dat | Hive des Benutzerkontos „Lokaler Dienst“ (Local Service). |
| HKU\S-1-5-20 | %SystemRoot%\ServiceProfiles\NetworkService\Ntuser.dat | Hive des Benutzerkontos „Netzwerkdienst“ (Network Service). |

## Technik
### Arbeitsweise der Registry

Die Registry besteht aus einzelnen Dateien, die als Hives bezeichnet werden. Jeder dieser Hives enthält einen Registry-Baum, wobei der erste Schlüssel in der Datei die Wurzel (root) des Baumes darstellt. Manche Registry-Bäume haben kein Wurzelverzeichnis, sind nur Spiegelungen oder volatil.
Hives sind in Datenblöcke zu je 4096 Bytes unterteilt. Der Hive kann nur blockweise vergrößert oder verkleinert werden, d. h. nur in Schritten von ±4kB. Der erste Block eines Hives ist der Basisblock, der Verwaltungsdaten wie die Signatur „regf“, Sequenznummern, Zeitstempel des letzten Schreibzugriffes im Hive usw. enthält. Die Daten der Registry werden in Zellen (cells) abgelegt, welche Schlüssel, Wert, Security Descriptor, eine Liste der Unterschlüssel oder Schlüsselwerte enthalten können. Ein Feld am Anfang der Zelle beschreibt den Typ und die Größe. Wird eine neue Zelle in den Hive gelegt und ist dafür eine Expansion des Hives nötig (+4096 Bytes), wird ein Behälter (bin) geschaffen, der die Zelle und den Leerraum des Blockes beinhaltet. Der Raum zwischen dem Ende der Zelle und dem Ende des Behälters kann später mit weiteren Zellen gefüllt werden.
Die Unterteilung der Registry in Behälter (bin) und Zellen (cell) ermöglicht eine effiziente Arbeitsweise: Da Behälter seltener neu zugewiesen werden als Zellen, kann die Zahl der (Ent)ladevorgänge gesenkt werden, wenn direkt ganze Behälter statt einzelner Zellen in den Arbeitsspeicher geladen werden. Optional können auch nur Behälter, die Schlüssel enthalten, in den Arbeitsspeicher geladen werden; die leeren Behälter werden dann ignoriert. Wenn eine Zelle angelegt oder entfernt wird, fragmentiert der Inhalt der Behälter mit der Zeit, es stehen also verschieden große Lücken. Deshalb wird die Registry kontinuierlich defragmentiert: Wenn ein Behälter leer wird, werden die leeren Behälter in möglichst zusammenhängende Anschnitte gelegt. Ferner werden die Zellen zusammengeführt, die durch Löschungen fragmentiert wurden.
Das Finden von Zellen und Werten findet durch Anspringen statt: Eine Schlüssel-Zelle enthält einen Zellen-Index, der Zeiger (Informatik) auf Unterschlüssel-Zellen enthält. Um die Unterschlüssel zu finden, ist in den Zellen auch eine alphabetisch sortierte Liste der Unterschlüssel enthalten, welche mit dem jeweiligen Zellen-Index verknüpft sind und per binärer Suche effizient durchsucht werden können. Die folgende Grafik veranschaulicht die Sprünge von Zelle zu Zelle in einem Registry-Hive, um Werte (Val 1, Val 2) oder Unterschlüssel (root, Sub Key) auszulesen.
Für den Zugriff wird erst den Basisblock angesprungen, dann folgt der Sprung auf den Wurzelschlüssel. Von diesem Schlüssel aus dann zum einen zu einer Wert-Listen-Zelle (hellblau), wo die Orte der Wert-Zellen hinterlegt sind. Wenn also diese Orte ermittelt sind, kann der Zeiger auf die Wert-Zellen Val 1 und Val 2 springen. Andererseits wird vom Wurzelschlüssel aus eine Unterschlüssel-Listen-Zelle (dunkelblau) angesprungen, welche die Adressen der Unterschlüssel (Sub Key) beinhaltet.
Es gibt fünf verschiedene Arten von Zellen:
* Die Schlüssel-Zellen (key cell) enthalten den Zeitstempel der letzten Aktualisierung, ein Zellen-Index der Über- und Unterzellen, und ein Index zur Sicherheitsbeschreibungszelle (security descriptor cell) sowie den Namen des Schlüssels.
* Die Wert-Zellen (value cell) enthalten die Werte des Schlüssels und auch Typ (REG_DWORD, REG_BINARY) und Namen des Wertes.
* Unterschlüssel-Listen-Zellen (Subkey-list cell) enthalten eine Liste der Unterschlüssel eines Schlüssels, mit deren Zellen-Index.
* Wert-Listen-Zellen (Value-list cell) enthalten eine Liste der Werte ihres Schlüssels und ihres Zellen-Indexes.
* Sicherheitsbeschreibungszellen (Security-descriptor cell) enthalten die Zugriffssteuerungsliste und andere sicherheitsrelevante Einstellungen eines Schlüssels. Mehrere Knoten können sich eine Sicherheitsbeschreibungszelle teilen.
Bei Suchen werden alle nötigen Hives in den Auslagerungsspeicher (pagefile.sys) geladen, das Original auf der Festplatte muss also nicht jedes Mal neu eingelesen werden. Nur beim Booten wird der System-Hive komplett in den Arbeitsspeicher geladen.
Alle 5 Sekunden werden alle vorliegenden Änderungen in Hives in des Festplatten-Abbild zurückübertragen. Eine Wiederherstellung im Falle eines Systemabsturzes wird mit Hilfe von *.log-Dateien ermöglicht.
Benötigt ein Programm Zugriff auf einen Pfad in der Registry, kann es das über eine Betriebssystemschnittstelle anfragen. Der Zugriff auf die Registry erfolgt dann durch einen vom Betriebssystemkern angestoßenen Prozess wie oben beschrieben. Ist der Zielschlüssel gefunden, baut der Prozess ein Schlüsselobjekt, das über den Betriebssystemkern an das anfragende Programm zurückgegeben wird.

### Speicherung von Anwendungseinstellungen

Anwenderprogramme können ihre eigenen Informationen in die Registry ablegen.
Für Anwendungen ist es nicht erforderlich, die Windows-Registrierung zu verwenden. NET-Framework-Anwendungen verwenden beispielsweise XML-Dateien zur Konfiguration, während portable Anwendungen ihre Konfigurationsdateien in der Regel zusammen mit ihren ausführbaren Dateien ablegen. Anwendungen die plattformunabhängig sind, wie z. B. Firefox oder VLC speichern ihre Einstellungen in Konfigurationsdateien, die speziell für ihre Bedürfnisse gestaltet sind. Viele Anwendungen benutzen die Windows-Registrierung nur spärlich, um von nur in Windows verfügbaren Schnittstellen unabhängig zu sein.
Es ist dem Programmhersteller überlassen, ob diese Informationen in die Registrierungsdatenbank oder in einem der unten aufgelisteten gemeinsamen Ordnern abgelegt werden sollen (Stand: Windows 10):
Nicht benutzerbezogen:
* %programdata% ist das Verzeichnis der Daten, die alle Benutzer betreffen (auf Windows-10-Systemen: C:\ProgramData). Für das Anlegen von Ordnern und Dateien dort werden Administratorrechte benötigt. Daher werden diese durch das Installationsprogramm des Anwenderprogramms angelegt, die entsprechende Ordner können dabei so konfiguriert werden, dass auch Programme, die unter dem Benutzerkontext laufen, Schreibzugriff darauf haben.
Benutzerbezogen:
* %userprofile%\AppData\Roaming: Die hier hinterlegten Ordner ziehen mit dem Benutzer um, wenn sich dieser an einem anderen Rechner der Domäne anmeldet.
* %userprofile%\AppData\Local: Die dort abgelegten Einstellungen sind an den Rechner gebunden.
* %userprofile%\AppData\LocalLow ist ein Sandbox-Verzeichnis mit niedriger Verbindlichkeitsstufe.

## Manuelle Bearbeitungsmöglichkeiten
### Registrierungs-Editor

Um manuell in der Registrierungsdatenbank zu editieren, stellt Windows den Registrierungs-Editor regedit.exe bereit. Dieser kann in der Suchleiste durch Eingabe von regedit aufgerufen werden. In der linken Spalte werden die Hives und Schlüssel-Zellen hierarchisch abgebildet, rechts werden die dazugehörigen Wert-Zellen eines Schlüssels samt ihrem Inhalt einzeln aufgelistet. Die Schlüssel-Listen-Zellen werden nicht dargestellt, sondern nur durch die Baumstruktur der Schlüssel abstrahiert. Die Wert-Listen-Zellen sind ebenfalls nicht sichtbar, bilden aber die Struktur der Liste rechts. Die Sicherheits-Beschreibungs-Zellen werden durch das Kontextmenü abstrahiert, wenn auf einen Schlüssel Rechtsklick > Berechtigungen… ausgeführt wird.
Die gesamte Registry kann exportiert werden, wenn auf das Symbol „Computer“ Rechtsklick > Exportieren ausgeführt wird. Gerade nicht eingehängte Teile, z. B. Schema.DAT und Components.DAT bleiben dabei aber unberücksichtigt. Wird ein (Unter)Schlüssel angewählt und exportiert, wird dieser samt seinen Unterstrukturen in eine Registrierungsdatei mit der Dateiendung *.reg geschrieben, welche in Unicode kodiert und damit menschenlesbar ist. Wird ein Schlüssel gewählt und im Fenstermenü Datei > Drucken… gewählt, werden auch die Informationen der Schlüssel-Zellen ausgedruckt, welche im Registrierungs-Editor nicht angezeigt werden, aber Teil der Zelle sind (zum Beispiel den letzten Schreibzugriff und der Klassenname). Die *.reg-Dateien sind Unicode-Textdateien mit der Zeichenfolge „Windows Registry Editor Version 5.00“ in der ersten Zeile. Die Syntax ist wie folgt:
Wenn der Standardwert eines Schlüssels bearbeitet werden soll, wird ein At-Zeichen vorangestellt:
Zeichenketten ("string values") benötigen keine Werttyp-Angabe. Pfade in Wert-Zellen müssen aber mit „\\“ geschrieben werden, einzelne „"“ als „\"“. Für den Werttyp gibt es folgende hex-Abkürzungen:
Ein vorangestelltes Minus entfernt den Schlüssel:
Werte in einem Schlüssel werden durch ein „-“ nach dem Wertnamen entfernt:
wobei @=- den Standardwert entfernt und "MeineMeinung"=- die Zeichenkette MeineMeinung und seinen Wert. In die Reg-Daten können auch Kommentare einfließen:
Die Reg-Dateien werden in die Registrierungsdatenbank gelesen, wenn sie doppelt geklickt werden. Ein Editieren ist mit Rechtsklick > Bearbeiten möglich.

### PowerShell

Seit dem Erscheinen der Windows PowerShell gibt es eine weitere sehr einfache Möglichkeit, die Registry zu verwalten. Dabei kann man auf die Registry direkt über die Konsole oder durch ein Shellskript wie auf ein herkömmliches Laufwerk zugreifen. Im „normalen“ Verzeichnis navigiert man mit den Aliassen ls um sich Unterverzeichnisse anzeigen zu lassen, cd <ziel> um ein Unterverzeichnis anzunavigieren, cd .. um ein Verzeichnis zurückzugehen usw. Gibt man beispielsweise cdHKLM: ein, wechselt man auf den Hauptschlüssel HKEY_LOCAL_MACHINE. Zu den Unterschlüsseln gelangt man ebenfalls über den Befehl cd oder in der Langform Set-Location. Der Befehl Get-ItemProperty. zeigt alle Eigenschaften (Registry-Einträge), die für den aktuellen Registryschlüssel gespeichert sind. Auf diese Weise lassen sich beispielsweise durch Eingabe der folgenden Befehlsfolge in der PowerShell alle Einträge des Run-Schlüssels anzeigen:
Nach dem Eingeben erfolgt unter anderem (PSPath, PSParentPath, PSChildName, PSProvider) als Ausgabe PSDrive: HKCU. Gleiches gilt, wenn man die Laufwerke des Rechners durch den Befehl Get-PSDrive anzeigen lässt, wobei hier nicht alle Registry-Laufwerke angezeigt werden. Wie bereits oben im Anschnitt „Arbeitsweise der Registry“ gezeigt, wird die Registry von Windows selbst wie ein Laufwerk/Gerät verwaltet, was in der PowerShell auch sichtbar wird. Mit dem Befehl cd C:\ oder einem anderen Laufwerksbuchstaben wechselt die PowerShell wieder in die Welt des Object Managers / Datei-Explorers zurück.
Auch ein indirektes Auslesen der Registry wird damit möglich: Mit den Befehlen $key="HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" wird der Pfad geholt und in die Variable $key geschrieben, $wert="Test" holt den Wert „Test“ und steckt ihn in die Variable $wert, und mit (Get-ItemProperty $key).$wert kann die Eigenschaft „Test“ im Schlüssel „Run“ ausgegeben werden, hier also der Pfad des Autostarteintrages.
Der Befehl New-Item HKCU:\Software\Wikipedia (Alias: md) legt einen neuen Schlüssel namens „Wikipedia“ an, Remove-Item HKCU:\Software\Wikipedia (Alias: del) entfernt ihn wieder. Mit New-ItemProperty -Path HKCU:\SOFTWARE\Wikipedia -Name MeineMeinung -PropertyType String -Value WikipediaIstGut wird eine Zeichenfolge namens „MeineMeinung“ mit dem Wert „WikipediaIstGut“ im Schlüssel „Wikipedia“ abgelegt. Neben String (REG_SZ) sind ExpandString (REG_EXPAND_SZ), Binary (REG_BINARY), DWord (REG_DWORD), MultiString (REG_MULTI_SZ) und QWord (REG_QWORD) ebenfalls zulässig.

### Konsolenregistrierungsprogramm

Das Konsolenregistrierungsprogramm reg.exe läuft nur innerhalb einer Eingabeaufforderung cmd.exe, wobei die Befehle auch in der PowerShell eingesetzt werden können. Die Syntax ist dabei sehr einfach, der Nachteil aber die fehlende Befehlszeilenergänzung, was das Risiko von Schreibfehlern erhöht. Die Syntax zum Abfragen von Schlüsseln ist wie folgt:REG QUERY Schlüssel(pfad), mit den angehängten optionalen Parametern /v Wert (sucht nach einem bestimmten Registrierungswert), /ve (sucht nach dem Standard- oder leeren Wert), und /s (sucht nach allen Unterschlüsseln und Werten). Der Befehl
in einer cmd.exe eingegeben gibt eine Liste aller Autostarteinträge des Run-Schlüssels im Benutzer-Hive zurück. Die Syntax zum Anlegen von Schlüsseln ist wie folgt: REG ADD Schlüssel mit den angehängten optionalen Parametern /v Wert (hinzuzufügender Wert unter dem Schlüssel), /ve (fügt einen Standardwert hinzu), /t (Datentypen: REG_SZ | REG_MULTI_SZ | REG_DWORD_BIG_ENDIAN | REG_DWORD | REG_BINARY | REG_DWORD_LITTLE_ENDIAN | REG_NONE | REG_EXPAND_SZ), /s (bestimmt das Trennzeichen in der Datenzeichenfolge), /d (Daten), und /f (Überschreiben). Der Befehl
legt im Autostartschlüssel „Run“ die Zeichenfolge (REG_SZ) namens „Test“ an, welche als Wert „calc.exe“ hat. Würde dieser Schlüssel beibehalten, würde sofort nach dem Einloggen des Users der Taschenrechner aufpoppen. Die Syntax zum Entfernen von Schlüsseln ist wie folgt: REG delete Schlüssel mit den angehängten optionalen Parametern /v Wert (zu löschender Wert unter dem Schlüssel), /ve (löscht den Wert des Standardwertes), /va (löscht alle Einträge des Schlüssels), und /f (für “mit Gewalt”). Der Befehl
löscht die Zeichenfolge „Test“ mit ihrem Wert „calc.exe“. Der böse Taschenrechner ist gebannt. Mit dem Befehl REG COPY Schlüssel1 Schlüssel2 wird der Schlüssel 1 an die Position von Schlüssel2 kopiert. Mit dem Parameter /s werden die kompletten Unterschlüssel mitgenommen, /f erzwingt das Kopieren. Weitere Befehle wie Save, Load, Unload, Restore, Compare, Export, Import usw. usf. sind möglich.

## Ausfallsicherheit

Aufgrund der Tatsache, dass in der Registry große Teile der Systemkonfiguration gespeichert sind, wird diese oft als Single Point of Failure angesehen. Eine Beschädigung der Registrierungsdatenbank kann das Starten des Betriebssystems erschweren oder gar unmöglich machen. Aufgrund dessen werden eine Reihe von Maßnahmen ergriffen, die einer Beschädigung der Registrierungsdatenbank vorbeugen oder diese rückgängig machen können:
* Durch den in Windows Vista eingeführten Kernel Transaction Manager können mehrere Einzeloperationen zu einer Transaktion zusammengefasst werden, die entweder als Ganzes erfolgreich verläuft, oder durch einen Rollback rückgängig gemacht werden kann, was inkonsistente Zustände verhindern soll.
* Ein Schutz vor inkonsistenten Zuständen wird auch durch die Implementierung der Registry selbst gewährleistet, da Änderungen an der Registry in Logdateien protokolliert werden. Bricht ein Schreibvorgang unerwartet ab (z. B. durch einen Stromausfall), nachdem bereits ein Teil der Daten verändert wurde, können diese Änderungen so wieder zurückgenommen werden.
* Auch das Dateisystem, in dem die Dateien der Registry gespeichert sind, kann einer Beschädigung entgegenwirken. So besitzt NTFS, das in allen modernen Windows-Versionen eingesetzt wird, weitreichende Fehlerüberprüfungs- und Reparaturmechanismen.
* Der besonders sensible Abschnitt SYSTEM wurde in früheren Windows-Versionen als Backup in der Datei SYSTEM.ALT gespeichert.

## Registry-Cleaner

Vielfach wird damit geworben, dass eine „Reinigung“ der Registrierungsdatenbank notwendig oder wünschenswert sei, um einen Geschwindigkeits- und Stabilitätsvorteil zu erhalten.
Der Nutzen von sogenannten „Registry-Cleanern“ wird jedoch überwiegend angezweifelt und als Mythos eingestuft. So würden ungenutzte und damit überflüssige Einträge in der Registry nur einen verschwindend geringen Teil ausmachen, deren Bereinigung nicht ins Gewicht falle. Der US-amerikanische Autor und Most Valuable Professional Ed Bott schätzt den Nutzen als verschwindend gering ein und warnt gleichzeitig davor, dass ein fälschlicherweise entfernter Eintrag dazu führen könne, dass auf dem System installierte Programme nicht mehr ordnungsgemäß funktionieren. Die Nutzung von Registry-Cleanern sei somit abzulehnen: „Don't run registry cleaner programs, period.“ (deutsch: „Benutze keine Programme zum Bereinigen der Registry. Punkt.“). Microsoft selbst rät von der Bereinigung der Registrierung ab.
Auch in Testberichten konnte der vermeintliche Nutzen durch das Bereinigen der Registry nicht nachgewiesen werden: Die Webseite Windows Secrets testete die Reinigungsprogramme CCleaner und jv16 PowerTools 2011 und verglich diese mit der Windows-internen Datenträgerbereinigung. Bei beiden Programmen konnte kein Geschwindigkeitsvorteil gegenüber der Windows-Datenträgerbereinigung gemessen werden. Die Windows-Datenträgerbereinigung lässt die Registry jedoch unberührt und beschränkt sich auf das Löschen überflüssiger Dateien auf der Festplatte.
Bis hin zu Windows XP (inkl. Windows Server 2003) konnte der Bootvorgang scheitern, wenn Kernel und SYSTEM.DAT mehr als die ersten 16 MB Arbeitsspeicher belegten. Microsoft bot deshalb das hauseigene Tool „RegClean“ zum Entfernen unnötiger Registry-Einträge an. Dies ist aber bei allen modernen Windows-Versionen überflüssig.

## Sichern der Registrierung
### Windows 9x

Windows 95 sichert die Registrierung bei jedem erfolgreichen Start und speichert diese als SYSTEM.DA0 und USER.DA0 im Systemverzeichnis. Eine manuelle Sicherung ist mit dem Programm ERU.EXE möglich, das sich auf der Windows 95-CD befindet.
Unter Windows 98 und Windows Me existiert stattdessen das Programm SCANREG.EXE, das bei jedem erfolgreichen Start von Windows zahlreiche wichtige Systemdateien, darunter die Registrierung, sichert, aber auch manuell aufgerufen werden kann, um eine Sicherung anzulegen oder das System von einer Sicherung wiederherzustellen. Standardmäßig werden bis zu fünf Backups als CAB-Datei im Ordner %systemroot%\Sysbckup angelegt. Über eine INI-Datei können diese und weitere Einstellungen modifiziert werden. Aufgrund eines Programmfehlers sichert SCANREG.EXE die USER.DAT nicht, wenn diese nicht im Systemverzeichnis liegt, weil mehrere Benutzerprofile angelegt wurden.
Alle Versionen von Windows 9x bieten zudem die Möglichkeit, mittels des Registrierungseditors REGEDIT.EXE im MS-DOS-Modus die gesamte Registrierung in eine Registrierungsdatei zu exportieren und auch wieder zu importieren. Windows 9x sichert außerdem direkt nach Ende des Windows-Setups eine Kopie der SYSTEM.DAT unter dem Namen SYSTEM.1ST im Stammverzeichnis der Festplatte.

### Windows NT

Windows NT bis einschließlich Version 4.0 boten die Möglichkeit, eine Kopie der Registrierung unter dem Verzeichnis %systemroot%\repair anzulegen und diese bei Bedarf auf einer sogenannten Notfalldiskette zu sichern. Standardmäßig legt Windows eine solche Notfalldiskette am Ende des Setups an, eine Sicherungskopie der Registrierung und (optional) eine Notfalldiskette kann aber auch manuell durch Aufrufen des Programms RDISK.EXE erstellt werden. Standardmäßig werden die Dateien SAM und SECURITY nicht gesichert, es sei denn RDISK.EXE wird mit dem Parameter /S aufgerufen.
In Windows 2000 und Windows XP wird die Registrierung stattdessen über das Programm Sicherung (NTBACKUP.EXE) gesichert. Standardmäßig ist in der Windows XP Home Edition das Programm Sicherung nicht vorhanden, es kann aber von der Windows XP-CD nachinstalliert werden.
Der in Registrierungs-Editor regedit.exe erlaubt das Sichern und Wiederherstellen der gesamten Registrierung oder einzelner Ordner.

## Windows-Registrierungsdatenbank ohne Windows

Das für Linux- und Unix-Systeme verfügbare Win32-API namens Wine enthält eine eigene Implementation der Windows-Registrierungsdatenbank. Wine selbst legt seine eigenen Einstellungen darin ab. Daneben können andere Windows-Programme, die auf Wine laufen, ihre Einstellungen dort eintragen. Für Win32-Anwendungen erscheint die Registrierungsdatenbank genau gleich wie auf einem Windows-NT-System. Im Hintergrund befindet sich aber – anders als bei Windows-NT-Systemen und wie in unixoiden Systemen für Einstellungen üblich – keine Datenbank, sondern einfache ASCII-Textdateien. In den folgenden Dateien im Verzeichnis ~/.wine ist die Registrierungsdatenbank von Wine in Form lesbarer Texte enthalten:
| Datei | Schlüssel |
| system.reg | HKEY_LOCAL_MACHINE |
| user.reg | HKEY_CURRENT_USER |
| userdef.reg | HKEY_USERS\.Default |
Das ReactOS-Projekt, das versucht Windows-NT nachzubauen, übernimmt Teile von Wine, darunter auch die Umsetzung der Windows-Registrierungsdatenbank.

## Alternativen

In den meisten unixoiden Betriebssystemen, wie FreeBSD, macOS oder in den Linux-basierten gibt es keine zentrale Konfigurationsdatenbank, sondern zahlreiche zentral abgelegte Konfigurationsdateien.
Jedoch gibt es Projekte, die Registry-artige Datenbanken auch für unixoide Systeme bereitstellen wollen, beispielsweise Elektra oder die Gnome-Konfigurationsdatenbank GConf bzw. der Nachfolger DConf. GConf baute im Gegensatz zur Windows-Registry und DConf konsequent auf XML-Dateien auf, was die Möglichkeit bot, die Schlüssel mit jedem Texteditor oder XML-Parser zu lesen und bearbeiten. Ebenso legt Elektra die Schlüssel in Plain-text-Dateien ab, die z. B. mit Editoren wie vi bearbeitet werden können.
Apple setzt bei Mac OS X teilweise auf sogenannte Property Lists, die im XML-, JSON- oder in einem proprietären Binär-Format vorliegen können.