Estoy ejecutando una instalación limpia (solo hace unos días) de Windows 10 Home de 64 bits y tengo problemas para acceder a una clave de registro en particular. Cuando el editor de Office VBA (proceso de 32 bits bajo mi propia cuenta de usuario limitada) escanea el registro en busca de controles disponibles, encuentra el {0002DF01-0000-0000-C000-000000000046}CLSID en la rama HKCR\CLSIDs y obtiene un Acceso denegado al abrir la clave en modo lectura, lo que le impide continuo. Esta clave solo está presente en la sucursal HKLM y no en la sucursal HKCU. Al ver su valor predeterminado, es para "Internet Explorer (Ver 1.0)". Hay dos copias del mismo; uno directamente en la ruta Classes\CLSID, el otro en la ruta Classes\WOW6432Node\CLSID para procesos de 32 bits. Como se trata de Office de 32 bits, primero me centré en la versión WOW6432Node.
Mis pruebas hasta ahora:
- Esta clave ya tenía permiso de lectura para mi cuenta de usuario... ¿qué pasa?
- El propietario era TrustedInstaller (¿por qué él?), y los permisos se anularon explícitamente para esta clave (es decir, no se heredaron como sospechaba, ¿por qué?)
- Cambié el propietario a Administradores y agregué mi cuenta de usuario específica con permiso total. La pestaña "acceso efectivo" de RegEdit confirma que este usuario tiene permiso completo, pero el acceso denegado aún se activa cuando el IDE de VBA (que se ejecuta bajo esta misma cuenta de usuario) intenta leerlo.
- Cambié temporalmente el nombre de la clave (por ejemplo, reemplazando el primer "0" por un "1"). Según Process Monitor, el IDE de VBA ahora puede leer bien la clave renombrada: ¿ya no se deniega el acceso? Cambiarle el nombre nuevamente le devuelve el comportamiento anterior...
- Pensando que esto podría ser un conflicto entre la 'versión' de 32 y 64 bits de la misma clave, intenté hacer lo mismo con la versión de 64 bits de esta clave. Resultado: los permisos predeterminados ya eran lo suficientemente buenos, establecer la propiedad en Administradores funciona, darles a los administradores control total también funciona, pero luego cambiar el nombre de la clave en RegEdit como administrador no está permitido. RegEdit arroja un "Error al cambiar el nombre de la clave: el Editor del Registro no puede cambiar el nombre de {0002DF01-0000-0000-C000-000000000046}. Error al cambiar el nombre de la clave". (¡Guau, es información útil!) El uso de Process Monitor revela que la operación RegRenameKey de RegEdit también resulta en un acceso denegado aquí.
- Al ejecutar RegEdit con la cuenta del sistema usando
PsExec -s -i regedit.exe(cuenta confirmada a través del Administrador de tareas), todavía no se puede cambiar el nombre de la clave.
Parece que esto no es un problema de permisos per se; ¿Parece como si algún otro proceso estuviera monitoreando activamente el acceso a esta clave por nombre y negándolo? Independientemente de que se establezcan los permisos correctos, los administradores no pueden cambiar el nombre de la versión de 64 bits de la clave, y los procesos de 32 bits que intentan leer la versión de 32 bits de la clave también obtienen "acceso denegado". Supongo que dado que los procesos de 32 bits consultan la ruta genérica Classes\CLSID... (es decir, no con la ruta WOW6432Node explícitamente como lo hicieron mis cambios de nombre RegEdit), esto desencadena la misma captura aquí.
Para completar el cuadro: honestamente no recuerdo cuándo empezó a suceder esto; Lo noté por primera vez hace unas semanas cuando necesitaba nuevamente esta funcionalidad VBA IDE. Tengo instalado Sandboxie v5.18 junto con el Windows Defender predeterminado. Todo el software está parcheado y actualizado. Aparte de eso, no se instala ningún otro software de seguridad invasivo. Desactivar el servicio Sandboxie y Windows Defender tampoco ayudó, ni tampoco ejecutar Windows en modo seguro.
¿Alguien tiene alguna idea de lo que podría estar pasando?
El contexto para cualquiera que tenga curiosidad y/o necesite ayuda para solucionar este problema también: estoy usando Office 2010 profesional de 32 bits y encontré el error de VBA IDE que provoca que no pueda agregar controles adicionales a su caja de herramientas al diseñar formularios. en el IDE. Puedo seleccionar "Controles adicionales" durante todo el día (tanto desde el menú como desde el menú contextual emergente de la propia caja de herramientas), pero aparte de un breve destello del cursor cambiando de forma, nunca sucede nada: no hay ningún cuadro de diálogo "Controles adicionales". se abre en absoluto, no se muestran errores, nada. La razón por la que esto sucede es que al iterar a través del registro en busca de CLSID de tipo "control", el IDE de VBA simplemente deja lo que está haciendo cuando encuentra un error de "acceso denegado" al leer una clave de registro. Usando Process Monitor puede encontrar qué clave desencadenó el error de permiso y corregir los permisos establecidos hace que VBA vuelva a estar feliz. Desafortunadamente, el error está presente desde hace mucho tiempo y, aunque no se encuentra con tanta frecuencia, en mi opinión sigue siendo un mal diseño que no se ha solucionado.