J'exécute une installation propre (vieille de quelques jours seulement) de Windows 10 Home 64 bits et je rencontre des problèmes pour accéder à une clé de registre particulière. Lorsque l'éditeur VBA d'Office (processus 32 bits sous mon propre compte utilisateur limité) recherche dans le registre les contrôles disponibles, il {0002DF01-0000-0000-C000-000000000046} CLSID dans la branche HKCR \ CLSIDs et obtient un accès refusé lors de l'ouverture de la clé en mode lecture, ce qui l'empêche de continuer. Cette clé est présente uniquement dans la branche HKLM et non dans la branche HKCU. En voyant sa valeur par défaut, il correspond à "Internet Explorer (Ver 1.0)". Il y a deux copies pour cela; l'un directement dans le chemin d'accès Classes \ CLSID, l'autre dans le chemin d'accès Classes \ WOW6432Node \ CLSID pour les processus 32 bits. Puisqu'il s'agit d'Office 32 bits, je me suis d'abord concentré sur la version WOW6432Node.
Mes tests jusqu'à présent:
- Cette clé avait déjà une permission de lecture pour mon compte d'utilisateur ... Qu'est-ce qui donne?
- Le propriétaire était TrustedInstaller (pourquoi lui?) Et les autorisations ont été explicitement remplacées pour cette clé (c'est-à-dire non héritées comme je le soupçonne - pourquoi?)
- J'ai changé le propriétaire en Administrateurs et ajouté mon compte d'utilisateur spécifique avec une permission complète. L'onglet "accès effectif" de RegEdit confirme que cet utilisateur dispose alors d'une autorisation complète, mais l'accès refusé est toujours déclenché lorsque l'EDI VBA (s'exécutant sous ce même compte d'utilisateur) tente de le lire?
- J'ai temporairement renommé la clé (par exemple en remplaçant le premier "0" par un "1"). Selon Process Monitor, l'EDI VBA peut désormais lire la clé renommée avec précision - aucun accès refusé plus longtemps!? Le renommer rend l'ancien comportement à nouveau ...
- Pensant que cela pourrait potentiellement être un conflit entre les «versions» 32 et 64 bits de la même clé, j'ai essayé de faire la même chose avec la version 64 bits de cette clé. Résultat: les autorisations par défaut étaient déjà suffisantes. Définir la propriété sur Administrateurs fonctionne, ce qui permet aux administrateurs de disposer d'un contrôle total également, mais renommer ensuite la clé dans RegEdit en tant qu'administrateur n'est pas autorisé. RegEdit génère une "erreur de renommage de clé - L'éditeur de registre ne peut pas renommer {0002DF01-0000-0000-C000-000000000046}. Erreur lors du changement de nom de clé". (wow, ce sont des informations utiles!) L'utilisation de Process Monitor révèle que l'opération RegRenameKey de RegEdit entraîne également un accès refusé ici.
- Exécuter RegEdit avec le compte système en utilisant
PsExec -s -i regedit.exe(compte confirmé via le Gestionnaire des tâches), il est toujours impossible de renommer la clé.
Il semble donc que ce n’est donc pas un problème de permission en soi; il semble qu'un autre processus surveille activement l'accès à cette clé par son nom et le nie? Quels que soient les droits définis, les administrateurs ne peuvent pas renommer la version 64 bits de la clé, et les processus 32 bits essayant de lire la version 32 bits de la clé obtiennent également un «accès refusé». Je suppose que puisque les processus 32 bits interrogent le chemin générique Classes \ CLSID ... (c’est-à-dire pas avec le chemin WOW6432Node de manière explicite comme le faisaient mes renames RegEdit), cela déclenche la même capture ici.
Pour compléter le tableau: honnêtement, je ne me souviens pas du moment où cela a commencé; Je l'ai remarqué pour la première fois il y a quelques semaines lorsque j'avais de nouveau besoin de cette fonctionnalité IDE VBA. Sandboxie v5.18 est installé à côté de Windows Defender par défaut. Tous les logiciels sont corrigés et à jour. En dehors de cela, aucun autre logiciel de sécurité invasif n'est installé. Désactiver le service Sandboxie et Windows Defender n'a pas aidé non plus, et Windows non plus en mode sans échec.
Est-ce que quelqu'un a une idée de ce qui pourrait se passer?
Contexte pour ceux qui sont curieux et / ou qui ont besoin d'aide pour résoudre ce problème également: J'utilise Office 2010 Professional 32 bits et j'ai corrigé le bogue VBA IDE qui empêche de pouvoir ajouter des contrôles supplémentaires à votre boîte à outils lors de la conception de formulaires. dans l'IDE. Je peux sélectionner "Contrôles supplémentaires" toute la journée (dans le menu ainsi que dans le menu contextuel de la boîte à outils elle-même), mais à part un bref éclair de la forme du curseur qui change de forme, rien ne se passe jamais - pas de dialogue "Contrôles supplémentaires" ouvre que ce soit, aucune erreur ne s'affiche, rien. Cela s’explique par le fait que lorsqu’il parcourt le registre à la recherche de CLSID de type "contrôle", l’IDE VBA se contente de quitter ce qu’il fait quand il rencontre une erreur "accès refusé" lors de la lecture d’une clé de registre. À l'aide de Process Monitor, vous pouvez rechercher la clé qui a provoqué l'erreur d'autorisation. La correction des autorisations définies rend VBA heureux à nouveau. Malheureusement, le bogue est présent depuis longtemps, et bien qu’il ne soit pas rencontré fréquemment, l’OMI reste un mauvais modèle qui n’a pas été corrigé.
la source