Ich hatte das Problem, dass bei einem Windows 7 System der Schlüssel „HKEY_CURRENT_USER\Software\Classes“ nicht zugänglich war. Aufgefallen ist das aber erst bei der Installation eines neuen Programms. Da ich wegen der Fehleranalyse sowieso schon den Process Monitor von Sysinternals angeworfen hatte, dache ich mir, das Problem wirst du jetzt lösen.

Zunächst aber ein paar Hintergrundinformationen:

„HKEY_CURRENT_USER\Software\Classes“ ist kein Registry-Schlüssel sondern ein Registry-Link, der beim Anmelden des Benutzers durch die „Winlogon.exe“ erzeugt wird. Das kann man ganz leicht nachprüfen, da sich in der Datei „ntuser.dat“ (ruhig mal von einem anderen Account aus als Hive laden) dieser Schlüssel nicht befindet.

Der Registry Link „HKEY_CURRENT_USER\Software\Classes“ zeigt eigentlich auf „HKEY_USERS\<user-SID>_Classes“. „HKEY_USERS\<user-SID>_Classes“ wiederum kommt aus der Datei „%userprofile%\AppData\Local\Microsoft\Windows\UsrClass.dat“.

Nun also zurück zu meinem Problem:
Bei meinem Benutzeraccount fehlten sämtliche Unterschlüssel von „HKEY_CURRENT_USER\Software\Classes“. Der Schlüssel „HKEY_USERS\<user-SID>_Classes“ für diesen Benutzer war aber vorhanden und konnte mit einem administrativen Account eingesehen werden.

Ich vermutete ein Rechte-Problem und habe (während ich mit Process Monitor die Registry auf ACCESS_DENIED prüfte) einfach mal im Schlüssel „HKEY_USERS\<user-SID>_Classes“ versucht, die Berechtigungen komplett durchzuvererben.

Tatsächlich spuckte der Process Monitor bei einigen Schlüsseln einen „ACCESS_DENIED“-Fehler aus. In meinem Fall waren es einige Schlüssel unterhalb von „HKEY_USERS\<user-SID>_Classes\VirtualStore\MACHINE\SOFTWARE\Wow6432Node“.

Für die betroffenen Schlüssel musste ich zunächst den Besitz übernehmen und dann die Rechte abändern. Zum Schluss lief dann die Rechtevererbung ohne Fehler durch und der Process Monitor zeigte auch keine Probleme mehr an.

Zusätzlich habe ich noch überprüft, ob der Benutzer überhaupt Schreibrechte für die Datei „%userprofile%\AppData\Local\Microsoft\Windows\UsrClass.dat“ hat, das war der Fall.

Nachdem ich den Benutzer abgemeldet und neu angemeldet hatte, waren wieder alle Unterschlüssel unter „HKEY_CURRENT_USER\Software\Classes“ vorhanden.

Ich vermute das Problem kam dadurch, dass jemand eine etwas betagte Software als Domänen-Administrator installiert hatte. Ich bin froh, dass es jetzt funktioniert.

Dieser Artikel hat mich auf die richtige Spur geführt, deswegen möchte ich ihn hier auch nochmal erwähnen:
Troubleshooting the Missing Classes Root Key…