Estou executando uma instalação limpa (apenas alguns dias atrás) do Windows 10 Home de 64 bits e encontro problemas ao acessar uma chave de registro específica. Quando o editor Office VBA (processo de 32 bits em minha própria conta de usuário limitada) verifica o registro em busca de controles disponíveis, ele atinge o {0002DF01-0000-0000-C000-000000000046}CLSID na ramificação HKCR\CLSIDs e obtém um Acesso negado ao abrir a chave no modo de leitura, o que impede que continuando. Esta chave está presente apenas na ramificação HKLM e não na ramificação HKCU. Vendo o valor padrão, é para "Internet Explorer (Ver 1.0)". Existem duas cópias dele; um diretamente no caminho Classes\CLSID, o outro no caminho Classes\WOW6432Node\CLSID para processos de 32 bits. Como este é o Office de 32 bits, concentrei-me primeiro na versão WOW6432Node.
Meus testes até agora:
- Essa chave já tinha permissão de leitura para minha conta de usuário... o que acontece?
- O proprietário era TrustedInstaller (por que ele?), E as permissões foram explicitamente substituídas por essa chave (ou seja, não herdadas como eu suspeitava - por quê?)
- Mudei o proprietário para Administradores e adicionei minha conta de usuário específica com permissão total. A guia "acesso efetivo" do RegEdit confirma que este usuário tem permissão total sobre ele, mas o acesso negado ainda é acionado quando o IDE do VBA (em execução nesta mesma conta de usuário) tenta lê-lo?
- Renomeei temporariamente a chave (por exemplo, substituindo o primeiro "0" por "1"). De acordo com o Process Monitor, o IDE do VBA agora pode ler a chave renomeada sem problemas - nenhum acesso negado mais!? Renomeá-lo de volta retorna o comportamento antigo ...
- Pensando que isso poderia ser um conflito entre a 'versão' de 32 e 64 bits da mesma chave, tentei fazer o mesmo com a versão de 64 bits desta chave. Resultado: as permissões padrão já eram boas o suficiente, definir a propriedade para Administradores funciona, dar aos Administradores controle total também funciona, mas renomear a chave no RegEdit como admin não é permitido? RegEdit gera um "Erro ao renomear chave - O Editor do Registro não pode renomear {0002DF01-0000-0000-C000-000000000046}. Erro ao renomear a chave." (uau, isso é uma informação útil!) O uso do Process Monitor revela que a operação RegRenameKey do RegEdit também resulta em um acesso negado aqui.
- Executando o RegEdit com a conta do sistema usando
PsExec -s -i regedit.exe(conta confirmada via Gerenciador de tarefas), ainda não é possível renomear a chave.
Parece que este não é um problema de permissão em si; parece que algum outro processo está monitorando ativamente o acesso a essa chave pelo nome e negando-a? Independentemente das permissões corretas serem definidas, os administradores não podem renomear a versão de 64 bits da chave, e os processos de 32 bits que tentam ler a versão de 32 bits da chave também obtêm 'acesso negado'. Presumo que, como os processos de 32 bits consultam o caminho genérico Classes\CLSID... (ou seja, não com o caminho WOW6432Node explicitamente nele, como minhas renomeações RegEdit fizeram), isso aciona a mesma captura aqui.
Para completar o quadro: sinceramente não me lembro quando isso começou a acontecer; Percebi isso pela primeira vez há algumas semanas, quando precisei dessa funcionalidade do VBA IDE novamente. Tenho o Sandboxie v5.18 instalado junto com o Windows Defender padrão. Todo o software está corrigido e atualizado. Além disso, nenhum outro software de segurança invasivo está instalado. Desligar o serviço Sandboxie e o Windows Defender também não ajudou, nem executar o Windows no modo de segurança.
Alguém tem alguma ideia do que pode estar acontecendo?
O contexto para qualquer pessoa curiosa e/ou que precise de ajuda para corrigir isso também: estou usando o Office 2010 profissional de 32 bits e encontrei o bug do VBA IDE que resulta na impossibilidade de adicionar controles adicionais à sua caixa de ferramentas ao projetar formulários no IDE. Posso selecionar "Controles adicionais" o dia todo (no menu e também no menu de contexto pop-up da própria caixa de ferramentas), mas, além de um breve piscar do cursor mudando de forma, nada acontece - nenhuma caixa de diálogo "Controles adicionais" abre de qualquer maneira, nenhum erro é mostrado, nada. A razão pela qual isso acontece é que, ao iterar pelo registro em busca de CLSIDs do tipo "controle", o IDE do VBA simplesmente encerra o que está fazendo quando encontra um erro de 'acesso negado' ao ler uma chave de registro. Usando o Process Monitor, você pode descobrir qual chave acionou o erro de permissão e corrigir as permissões definidas deixa o VBA feliz novamente. Infelizmente, o bug já está presente há muito tempo e, embora não seja encontrado com tanta frequência, na IMO ainda é um design ruim que não foi corrigido.