Windows agindo como se houvesse dois registros?

Question

Temos um software que salva suas informações de conexão no registro do Windows, em HKLM\Software . É apenas uma aplicação de 32 bits, não 64 bits, e estamos bem conscientes dos diferentes locais para isso ( WOW6432Node ). Temos 150% de certeza de que estamos lendo e escrevendo as mesmas entradas de registro - nosso software tem mais de 20 anos.

No mês passado, 3 computadores, dois deles o Windows 7 e o terceiro Windows 10, têm agido de forma muito estranha. A única maneira de descrevê-lo é como se o Registro do Windows tivesse sido duplicado! Escrevemos informações de conexão no registro para que nosso aplicativo se conecte ao servidor. Mas lê entradas antigas que mudamos há muito tempo!

Parece que, se executarmos o aplicativo "Como Administrador", eles querem ser legais. Embora o usuário logado seja um administrador local do PC. Por exemplo, abrimos Regedit e alteramos uma dessas entradas. Execute nosso aplicativo e leia as entradas antigas de antes que ele fosse alterado, mas depois executamos o aplicativo como administrador e, de repente, ele obtém as entradas corretas.

Este é um problema conhecido? Oque esta acontecendo aqui? É alguma atualização do Windows que quebrou isso? Qualquer coisa que eu possa fazer para consertar isso?

    

Answer 1

Como programador, corri para essa situação com frequência; uma empresa irá mais de 20 anos usando um aplicativo que foi escrito para uma versão mais antiga do Windows e será forçado a atualizar, apenas para descobrir que as atualizações de segurança do Windows ou a própria versão do Windows tornaram seu software obsoleto sob o capô em vez de na prática.

O que provavelmente está acontecendo aqui é que seu aplicativo está se envolvendo em um problema de política de grupo. A política de grupo pode ser usada para modificar o registro ou o comportamento do registro com base em qual usuário está logado . Eu procuraria a causa raiz do problema, mas se você adicionar o que está fazendo no registro para que o aplicativo funcione, pode haver novas informações sobre o motivo pelo qual isso está acontecendo.

Um problema que isso traz à tona é que, a partir do Windows funcionando dessa maneira, ele pode colocar os desenvolvedores à mercê do grupo de TI da rede, já que eles geralmente gerenciam as políticas de grupo. A maioria dos desenvolvedores modernos tenta ficar fora do sistema operacional agora ao desenvolver aplicativos e armazenar informações de configuração em bancos de dados ou em arquivos de configuração locais. Embora mexer nas políticas de grupo possa levar a uma correção de curto prazo, é provável que a solução real seja alterar sua solução de software de modo que, seja o que for que esteja fazendo no registro, ela agora esteja cuidando sozinha. Qualquer um que diga "não, não devemos atualizar nosso software de 20 anos porque vai custar muito" está apenas chutando uma lata no caminho até um dia em que uma pequena mudança de TI interrompe o software completa e permanentemente e custa à organização um muito mais.

    

Answer 2

Como ainda não posso comentar minha reputação, deixe-me listar algumas sugestões de solução de problemas aqui, mesmo que não sejam "respostas" reais:

• Execute seu programa depois de iniciar o ProcMon (Process Monitor da SysInternals). Você pode colocar um filtro incluindo apenas o nome do seu programa (ou PID), e ele pode lhe dar algumas idéias de onde o programa está lendo, e / ou se algo está falhando ao longo do caminho.
• Ainda outra ferramenta sysinternals Process Explorer (ou Handle) também pode fornecer o caminho do registro (se você estiver mantendo a chave "aberta").
• Alguma chance de o seu programa ter alguma lógica que retorne a um valor anterior (armazenado em disco / arquivo de configuração, etc) quando falhar na leitura do registro? É estranho que você não esteja terminando com um valor de fallback padrão, mas um que foi gravado no registro em algum momento.

Answer 3

O problema pode estar relacionado à Virtualização do Registro.

O registro de redirecionamento do Windows grava no HKLM de software sem direitos administrativos para um local diferente, específico do usuário, no registro. Dar uma olhada HKEY_USERS\<User-SID>_Classes\VirtualStore

No site do Microsoft MSDN Virtualização do Registro

Prior to Windows Vista, applications were typically run by administrators. As a result, applications could freely access system files and registry keys. If these applications were run by a standard user, they would fail due to insufficient access rights. Windows Vista and later versions of Windows improve application compatibility for these applications by automatically redirecting these operations. For example, registry operations to the global store (HKEY_LOCAL_MACHINE\Software) are redirected to a per-user location within the user's profile known as the virtual store (HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software).

    

Answer 4

Pedi ao autor que usasse o regedit para pesquisar os dados antigos, a fim de para encontrar onde no registro está escondido. A resposta foi que os dados antigos não existem mais no registro, ainda é usado pelo programa.

Em vista disso, a única explicação que posso pensar para o programa "ler" valores antigos que não existem mais no registro, é que não está lendo nada. Uma questão de ilusão de ótica.

Eu acredito que o programa deve estar armazenando em cache os valores que ele lê, e usa seus últimos valores bons quando não consegue ler os novos valores do registro. (Ou talvez tenha alguns padrões internos para eles).

O problema deve ser uma questão de permissões. Isso explicaria porque quando é executado como administrador, ele consegue ler os novos valores do registro, já que com permissões de administrador não pode ser bloqueado.

Eu sugiro que você use o regedit e o Explorer para comparar as permissões na chave do Registro para o arquivo .exe do programa. Você pode usar regedit para adicionar a conta sob a qual o programa é executado, com permissão de leitura, para a chave em questão.