Was die Windows-Registry ist — und warum ihre Größe kaum eine Rolle spielt

Eine Datenbank, kein Sammelbecken

Strukturell ist die Registry ein Satz Dateien namens Hives: SAM, SECURITY, SOFTWARE und SYSTEM liegen in C:\Windows\System32\config, und jedes Benutzerprofil bringt sein eigenes NTUSER.DAT mit. Im regedit zeigen sie sich als die fünf bekannten Stammschlüssel: HKEY_CLASSES_ROOT für Dateizuordnungen und COM-Registrierung, HKEY_CURRENT_USER für Ihre Hälfte der Einstellungen, HKEY_LOCAL_MACHINE für die systemweite Ebene, in der sich Treiber und Dienste beschreiben, HKEY_USERS für alle geladenen Profile und HKEY_CURRENT_CONFIG für das beim Boot zusammengestellte Hardwareprofil. Werte gibt es in einer Handvoll Typen — Zeichenfolgen, DWORDs, QWORDs, Binärdaten — und mehr ist es ehrlicherweise nicht.

Beim Boot lädt der Kernel die Maschinen-Hives in den Speicher, und jede Anmeldung mountet darüber Ihr NTUSER.DAT als HKEY_CURRENT_USER. Jede spätere Einstellungssuche ist ein gezielter Abstieg entlang eines konkreten Schlüsselpfads, kein Scan: Will ein Programm einen Wert, fragt es genau diesen Schlüssel beim Namen ab. Schreibvorgänge puffert ein Lazy Writer, der Änderungen binnen weniger Sekunden auf die Platte schreibt — weshalb ein gezogener Stecker in seltenen Fällen einen Hive inkonsistent hinterlassen kann, sodass Windows beim nächsten Start eine Reparaturrunde dreht.

Warum eine fette Registry Speicherplatz kostet, nicht Tempo

Hier der Teil, den die „600.000 Fehler“-Branche hofft, dass Sie ihn nie lesen: Windows durchläuft die Registry nie von oben bis unten. Suchen gehen direkt zum benannten Schlüssel, daher benimmt sich ein auf 150 MB gewachsener SOFTWARE-Hive bei jeder einzelnen Abfrage exakt wie ein aufgeräumter — der Preis von Ballast ist Speicherplatz und Speicherbedarf, nicht Latenz. Die Hives werden einmal beim Boot geladen und gecacht; niemand parst sie pro Vorgang neu. Defragmentierungs- und Komprimierungs-Tools können die Dateien auf der Platte tatsächlich verkleinern, und das ist der komplette Nutzen: Auf einer SSD ist der gewonnene Platz die ganze Geschichte, Tempo gibt es dort nicht mehr zu holen.

Eben deshalb sind „verwaiste“ Einträge deinstallierter Programme träge. Ein Deinstaller, der einen toten Schlüssel liegen lässt, hat ein paar Kilobyte verschwendet; niemand zählt diesen Schlüssel auf, solange Sie nicht selbst den regedit öffnen und nachsehen. Die ehrlichen Ausnahmen sind eng und konkret: Ein kaputter Wert in einem Hot Path, den tatsächlich jemand liest — ein Kontextmenü-Handler, ein Image-File-Execution-Options-Schlüssel, eine defekte Dateizuordnung — hat reale Folgen. Doch das ist Schaden an einer bestimmten Adresse, und genau solchen Schaden verursachen „Cleaner“, die Tausende Einträge auf einmal löschen, eher, als dass sie ihn beheben.

Wo die Registry tatsächlich zubeißt — und wie man sie sicher anfasst

Ihren furchteinflößenden Ruf hat sich die Registry an genau drei Stellen verdient, und an zweien davon geht es um einen einzelnen falschen Wert, nicht um generelle Fäulnis. Verhalten Sie sich entsprechend: Vor jeder Änderung ein Backup, eine Sache nach der anderen, und niemals ein Tool starten, dessen Verkaufsargument ist, wie viel es löscht.

• Korruption — ein nicht ladender Hive kann den kompletten Boot stoppen; die Werkzeuge dafür sind die Systemdateiprüfung und die Reparaturumgebung, nicht Cleaner
• Fehlgetunte Tweaks — ein falscher Wert in einem Hot Path (Shell-Erweiterungen, IFEO, Dienste) hat sofortige, reale Folgen
• Malware-Persistenz — Autostart-Schlüssel und IFEO-Debugger-Hijacks sind klassische Verstecke, die man beim Namen kennen sollte
• Privatspuren — TypedPaths, RunMRU und RecentDocs protokollieren Ihre Aktivität im eigenen Hive
• Backups — vor jedem Edit im regedit den Schlüssel exportieren; auch Wiederherstellungspunkte erfassen die Registry
• RegBack — seit Windows 10 1803 ist die automatische Hive-Sicherung unter System32\config\RegBack standardmäßig aus; ein geplanter Task oder der Wert SetPeriodicBackup bringt sie zurück

Fragen und Antworten

Weiterlesen