Substituição Persistente da Integridade de Memória (VBS) Causando Conflitos com Drivers de Vídeo em Windows 10 21H2 Vinculado ao Domínio

Question

Substituição Persistente da Integridade de Memória (VBS) Causando Conflitos com Drivers de Vídeo em Windows 10 21H2 Vinculado ao Domínio

Jordan Cullin 0

Após uma recente implementação de protocolos avançados de proteção de endpoints em nossa rede corporativa, diversos colaboradores passaram a enfrentar falhas severas de renderização de hardware que impedem a inicialização de monitores secundários em notebooks. Especificamente, a ativação de mecanismos de proteção contra ameaças baseados em reputação acabou habilitando a Segurança Baseada em Virtualização (VBS) e a Integridade de Memória, o que agora está entrando em conflito direto com nossos drivers gráficos.

Apesar de tentarmos reverter essa configuração em estações de trabalho Windows 10 Professional x64 (21H2) totalmente atualizadas, retornando o Objeto de Política de Grupo (GPO) associado para o estado “Não Configurado”, o isolamento em nível de hipervisor continua ativo. Já verifiquei, por meio do Resultant Set of Policy (RSOP) e dos editores de política local, que não há diretivas superiores impondo essa configuração. Ainda assim, mesmo após zerar manualmente as chaves relevantes do Registro ou utilizar a interface gráfica nativa do Windows Security para desativar o recurso, o sistema continua sobrescrevendo os comandos.

Após uma longa tela de “Please wait” durante o ciclo obrigatório de reinicialização, a máquina inicia novamente com a Integridade de Memória reativada automaticamente. Como podemos desabilitar permanentemente essa proteção baseada em virtualização para restaurar a funcionalidade de múltiplos monitores para nossos colaboradores?

0 comentários

2 respostas

Sua resposta

Answer 1

Tracy Le 14,655 Assistente Independente

Olá Jordan Cullin ,

Gostaria de saber se a utilização da ferramenta de prontidão do Device Guard ou o comando bcdedit resolveu o bloqueio persistente da Integridade de Memória em suas estações de trabalho. Caso essas etapas tenham restaurado a funcionalidade dos monitores secundários, por favor, clique em "Aceitar Resposta".

Tracy.

0 comentários

Answer 2

Olá Jordan Cullin,

O comportamento que você está observando ocorre porque alterar o GPO de Segurança Baseada em Virtualização (VBS) para "Não Configurado" não reverte as configurações ativas; isso apenas deixa as chaves de registro permanentemente aplicadas no sistema. Além disso, se a política original foi implantada com a opção de Bloqueio UEFI (UEFI Lock) ativada, a exigência da Integridade de Memória (HVCI) foi gravada diretamente na NVRAM do firmware da placa-mãe. É por isso que o uso do Windows Security ou edições manuais no registro são imediatamente substituídos durante o boot, resultando na longa tela de espera enquanto o sistema operacional reativa a proteção no nível do hipervisor para espelhar a exigência do firmware.

Para resolver isso definitivamente e restaurar a funcionalidade dos monitores secundários, você deve primeiro configurar o GPO de VBS explicitamente para "Desabilitado", garantindo que as chaves em HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard reflitam o valor nulo. Em seguida, para limpar o bloqueio persistente na NVRAM, será necessário utilizar a ferramenta oficial da Microsoft baixando o Device Guard and Credential Guard hardware readiness tool e executando .\DG_Readiness_Tool.ps1 -Disable -AutoReboot via PowerShell com privilégios administrativos. Durante a inicialização subsequente, o usuário precisará estar fisicamente presente para pressionar a tecla solicitada pelo hardware (geralmente F3 ou F12) na tela preta do firmware, o que confirmará o opt-out e a remoção da política de segurança do UEFI.

Caso a presença física nas estações não seja viável no momento, uma alternativa técnica para contornar o bloqueio remotamente é desativar totalmente o carregamento do hipervisor executando bcdedit /set hypervisorlaunchtype off em um prompt de comando elevado, embora isso também impossibilite o uso de recursos independentes como o WSL2. A longo prazo, recomendo fortemente coordenar com seus fornecedores de hardware a atualização para drivers de vídeo baseados no modelo universal DCH, o que permitirá a reativação segura do HVCI no futuro sem induzir essas falhas de renderização.

Tracy Le.