Ich führe eine Neuinstallation (nur einige Tage alt) von Windows 10 Home 64 Bit aus und habe Probleme beim Zugriff auf einen bestimmten Registrierungsschlüssel. Wenn der Office VBA-Editor (32-Bit-Prozess unter meinem eigenen eingeschränkten Benutzerkonto) die Registrierung nach verfügbaren Steuerelementen durchsucht, stößt er auf die {0002DF01-0000-0000-C000-000000000046}CLSID im Zweig HKCR\CLSIDs und erhält eine Zugriffsverweigerung, wenn der Schlüssel im Lesemodus geöffnet wird, was eine Fortsetzung verhindert. Dieser Schlüssel ist nur im Zweig HKLM vorhanden und nicht im Zweig HKCU. Der Standardwert ist für „Internet Explorer (Ver. 1.0)“. Es gibt zwei Kopien davon: eine direkt im Pfad Classes\CLSID, die andere im Pfad Classes\WOW6432Node\CLSID für 32-Bit-Prozesse. Da es sich um Office 32 Bit handelt, habe ich mich zunächst auf die Version WOW6432Node konzentriert.
Meine Tests bisher:
- Dieser Schlüssel hatte bereits Leseberechtigung für mein Benutzerkonto ... was ist los?
- Der Besitzer war TrustedInstaller (warum er?), und die Berechtigungen für diesen Schlüssel wurden ausdrücklich überschrieben (d. h. nicht vererbt, wie ich vermutet hätte – warum?)
- Ich habe den Besitzer in Administratoren geändert und mein spezifisches Benutzerkonto mit voller Berechtigung hinzugefügt. Die Registerkarte „Effektiver Zugriff“ von RegEdit bestätigt, dass dieser Benutzer dann die volle Berechtigung dafür hat, aber der verweigerte Zugriff wird trotzdem ausgelöst, wenn die VBA IDE (die unter demselben Benutzerkonto ausgeführt wird) versucht, es zu lesen?
- Ich habe den Schlüssel vorübergehend umbenannt (z. B. indem ich die erste „0“ durch eine „1“ ersetzt habe). Laut Process Monitor kann die VBA-IDE den umbenannten Schlüssel jetzt problemlos lesen – kein Zugriff mehr verweigert!? Durch die Rückbenennung wird das alte Verhalten wiederhergestellt …
- Da ich dachte, dass dies möglicherweise ein Konflikt zwischen der 32- und der 64-Bit-Version desselben Schlüssels sein könnte, habe ich versucht, dasselbe mit der 64-Bit-Version dieses Schlüssels zu tun. Ergebnis: Die Standardberechtigungen waren bereits gut genug, das Festlegen des Eigentümers auf Administratoren funktioniert, das Erteilen der Vollzugriffsrechte an Administratoren funktioniert auch, aber dann ist das Umbenennen des Schlüssels in RegEdit als Administrator nicht zulässig? RegEdit gibt einen „Fehler beim Umbenennen des Schlüssels – Der Registrierungseditor kann {0002DF01-0000-0000-C000-000000000046} nicht umbenennen. Fehler beim Umbenennen des Schlüssels.“ aus (wow, das sind hilfreiche Informationen!) Die Verwendung des Prozessmonitors zeigt, dass die RegRenameKey-Operation von RegEdit auch hier zu einem verweigerten Zugriff führt.
- Beim Ausführen von RegEdit mit dem Systemkonto
PsExec -s -i regedit.exe(Konto über Task-Manager bestätigt) kann der Schlüssel immer noch nicht umbenannt werden.
Es scheint also, als ob dies kein Berechtigungsproblem an sich ist; es sieht so aus, als ob ein anderer Prozess den Zugriff auf diesen Schlüssel aktiv anhand des Namens überwacht und verweigert? Unabhängig davon, ob die richtigen Berechtigungen festgelegt sind, können Administratoren die 64-Bit-Version des Schlüssels nicht umbenennen, und 32-Bit-Prozessen, die versuchen, die 32-Bit-Version des Schlüssels zu lesen, wird ebenfalls „Zugriff verweigert“ angezeigt. Ich gehe davon aus, dass dies hier dieselbe Erfassung auslöst, da 32-Bit-Prozesse nach dem generischen Pfad „Classes\CLSID...“ abfragen (also nicht mit dem explizit darin enthaltenen Pfad „WOW6432Node“, wie es bei meinen RegEdit-Umbenennungen der Fall war).
Um das Bild zu vervollständigen: Ich kann mich ehrlich gesagt nicht erinnern, wann das angefangen hat; mir ist es zum ersten Mal vor ein paar Wochen aufgefallen, als ich diese VBA IDE-Funktionalität wieder brauchte. Ich habe Sandboxie v5.18 neben dem standardmäßigen Windows Defender installiert. Die gesamte Software ist gepatcht und auf dem neuesten Stand. Abgesehen davon ist keine andere invasive Sicherheitssoftware installiert. Das Ausschalten des Sandboxie-Dienstes und des Windows Defender hat auch nicht geholfen, und auch das Ausführen von Windows im abgesicherten Modus hat nicht geholfen.
Hat jemand eine Idee, was los sein könnte?
Der Kontext für alle, die neugierig sind und/oder Hilfe bei der Behebung dieses Problems benötigen: Ich verwende Office 2010 Professional 32 Bit und bin auf den VBA IDE-Fehler gestoßen, der dazu führt, dass ich beim Entwerfen von Formularen in der IDE keine zusätzlichen Steuerelemente zu meiner Toolbox hinzufügen kann. Ich kann den ganzen Tag lang „Zusätzliche Steuerelemente“ auswählen (sowohl aus dem Menü als auch aus dem Popup-Kontextmenü der Toolbox selbst), aber abgesehen von einem kurzen Aufblitzen des sich ändernden Cursorformulars passiert nie etwas – es wird überhaupt kein Dialogfeld „Zusätzliche Steuerelemente“ geöffnet, es werden keine Fehler angezeigt, nichts. Der Grund dafür ist, dass die VBA IDE beim Durchlaufen der Registrierung auf der Suche nach CLSIDs vom Typ „Steuerelement“ einfach abbricht, wenn beim Lesen eines Registrierungsschlüssels ein „Zugriff verweigert“-Fehler auftritt. Mit Process Monitor können Sie herausfinden, welcher Schlüssel den Berechtigungsfehler ausgelöst hat, und durch die Korrektur der festgelegten Berechtigungen funktioniert VBA wieder. Leider besteht dieser Fehler bereits seit längerer Zeit, und auch wenn er nicht so häufig auftritt, handelt es sich meiner Meinung nach dennoch um ein schlechtes Design, das nicht behoben wurde.