Surface Pro 8: como conciliar VT‑x/EPT, Device Guard e VMware no Windows 11 Pro

Se você administra um Surface Pro 8 rodando Windows 11 Pro 24H2 e depende do VMware Workstation 17 para executar máquinas virtuais com aceleração de hardware VT‑x/EPT, provavelmente já se deparou com um impasse: ao ativar Device Guard e Credential Guard (componentes da Segurança Baseada em Virtualização – VBS), o VMware exibe erro e se recusa a iniciar as VMs. Este artigo detalha por que isso acontece, mostra como diagnosticar o ambiente, descreve todas as soluções conhecidas e ajuda você a escolher a configuração que melhor equilibra segurança, conveniência e produtividade.

Visão geral do problema

Device Guard e Credential Guard criam uma partição de segurança isolada dentro do Hyper‑V para proteger credenciais e validar a integridade do kernel. Quando essa partição está ativa, ela monopoliza as instruções VT‑x/EPT que o VMware precisaria para expor virtualização assistida por hardware às suas VMs convidadas. O resultado prático é um erro semelhante a:

VMware Workstation and Hyper‑V are not compatible.
Remove the Hyper‑V role on Windows or disable Device Guard and Credential Guard.

Desativar a VBS faz o VMware voltar a funcionar, mas em muitos Surface Pro 8 a simples reconfiguração do Windows Hello for Business (PIN ou reconhecimento facial) força o sistema a reabilitar automaticamente partes do Device Guard, bloqueando novamente o VT‑x/EPT.

Por que ocorre o conflito entre VBS e VT‑x/EPT?

• Partição de segurança: a VBS ergue um “micro‑hypervisor” que executa código sensível fora do Windows hospedeiro; por padrão, esse micro‑hypervisor não compartilha extensões VT‑x/EPT.
• Design do Hyper‑V: o VMware cria um hipervisor do tipo 2 que espera ter acesso direto ao hardware. Quando o Hyper‑V (ou a VBS) já está presente, ele perde essa primazia.
• Comportamento do Surface: determinadas builds de firmware da família Surface voltam a habilitar a VBS sempre que o Windows Hello é configurado, mesmo que o administrador tenha desativado a funcionalidade via políticas.

Diagnóstico passo a passo

1. Checar estado da VBS
   Abra o Windows PowerShell como administrador e execute:
   Get‑CimInstance -ClassName Win32_DeviceGuard Procure o campo VirtualizationBasedSecurityStatus. Valor 0 significa VBS desativada.
2. Confirmar carga do Hyper‑V
   No Prompt de Comando (Admin):
   bcdedit /enum {current} | find "hypervisorlaunchtype" “Off” indica que o Hyper‑V não será carregado.
3. Revisar recursos opcionais
   Em Configurações > Aplicativos > Recursos opcionais > Mais recursos do Windows, verifique:
   • Hyper‑V
   • Plataforma de Máquinas Virtuais
   • Plataforma de Hipervisor do Windows
   Todos devem estar desmarcados se a prioridade é usar VT‑x/EPT no VMware.
4. Atualizar firmware e drivers
   Instale o pacote mais recente de firmware/UEFI para o Surface (inclui atualizações da câmera Windows Hello e do TPM).
5. Rodar o DGReadiness (opcional para ambientes corporativos)
   Se a política exigir, execute o script oficial DGReadinessTool_v3.6.ps1 -Disable para desativar Device Guard — pode ser necessário remover temporariamente o PIN.

Opções de configuração detalhadas

Situação desejada	Medida prática	Impacto no Windows Hello	Observações
Usar VMware com VT‑x/EPT (prioridade desempenho)	Desativar totalmente VBS (Device Guard, Credential Guard e Isolamento de Núcleo). Executar bcdedit /set hypervisorlaunchtype off. Desinstalar Hyper‑V, Plataforma de Hipervisor do Windows e Plataforma de Máquinas Virtuais.	Talvez seja necessário remover o PIN/rosto temporariamente e recriá‑lo. Em alguns Surface o Hello pode forçar a reabilitação da VBS.	Procedimento validado por vários usuários (Ziggy, Armend) em fóruns de TI.
Manter Windows Hello e virtualização	Adotar Hyper‑V (inclui WSL 2) como plataforma principal de VMs.	Windows Hello permanece ativo sem alterações.	Não cobre recursos únicos do VMware (snapshots portáveis, filtragem de tráfego em rede virtual complexa).
Alternativa de curto prazo	Desabilitar Hello e VBS somente enquanto o VMware estiver em uso.	Login via senha tradicional; sem biometria.	Útil em laboratórios acadêmicos ou testes eventuais.

Recomendações para diferentes cenários

Ambientes corporativos com política de alta segurança

Se a organização exige Device Guard/Credential Guard por compliance, considere migrar seus workloads para:

• Hyper‑V no próprio Surface – mantém a VBS sem impactos.
• Windows Sandbox para testes rápidos que não requerem persistência.
• Host físico dedicado rodando VMware ESXi para laboratórios, deixando o Surface exclusivamente para tarefas administrativas.

Desenvolvedores que precisam do ecossistema VMware

Funcionalidades como restauração de snapshots consistentes entre hosts, laboratórios virtuais complexos ou clonagem ligada podem justificar a preferência pelo VMware. Se esse for o seu caso:

1. Desative a VBS conforme indicado.
2. Documente o procedimento e acompanhe atualizações de firmware: a Microsoft pode alterar o comportamento do Hello em builds futuras.
3. Crie scripts de verificação pós‑atualização (PowerShell) para garantir que VirtualizationBasedSecurityStatus permaneça 0.

Profissionais de campo ou educação

Quando a biometria facilita o acesso em locais sem teclado, mas algumas sessões exigem VMware, avalie a estratégia “ativar Hello apenas quando necessário”. O processo seria:

1. Trabalhar com Hello (VBS ativa) no dia a dia.
2. Antes de abrir o VMware, usar script que desliga a VBS e reinicia a máquina (DGReadinessTool … -Disable).
3. Finalizado o uso do VMware, reativar o Hello (DGReadinessTool … -Enable) e reiniciar novamente.

Esse método insere um pequeno atrito, mas mantém ambas as funcionalidades sob demanda.

Boas práticas adicionais

• Versionamento de snapshots: ao migrar para Hyper‑V, use Checkpoints apenas como marca‑d’água temporária; para produção, prefira backup full image.
• Monitoramento de atualizações: assine o canal de firmware Release Notes do Surface e o blog de política de segurança da Microsoft para ser avisado quando houver mudanças na interação Hello × VBS.
• Políticas de Grupo: centralize a configuração via GPO ou Intune para garantir consistência entre dispositivos. Desativações manuais tendem a ser revertidas por scripts de compliance.
• Registro de mudanças: use New‑EventLog e Write‑EventLog em PowerShell para gravar quando a VBS é ativada ou desativada, ajudando na auditoria.

Perguntas frequentes (FAQ)

Windows Hello exige Device Guard ou Credential Guard?

Não. O Hello utiliza o TPM e credenciais vinculadas à conta (Hello for Business). Entretanto, em certos firmwares Surface, ativar o Hello seta flags de VBS nos bastidores.

WSL 2 conflita com o VMware?

Sim. O WSL 2 depende do Hyper‑V, o que automaticamente reserva as instruções de virtualização. Se você precisa do VMware para VT‑x, mantenha o WSL 1 ou use contêineres Docker baseados em Hyper‑V e aceite a limitação.

É seguro desativar completamente a VBS?

Depende do seu modelo de ameaça. A VBS mitiga pass‑the‑hash, secures boot e ataques de escalonamento de privilégio que buscam credenciais LSASS. Avalie a política de segurança antes de abrir mão dessas proteções.

Posso habilitar apenas o Memory Integrity (HVCI) sem bloquear o VMware?

Não. O Memory Integrity também utiliza o Hyper‑V em modo isolado, gerando o mesmo conflito.

Conclusão

No estado atual do Surface Pro 8 e do Windows 11 Pro 24H2, é tecnicamente inviável manter simultaneamente:

1. Device Guard / Credential Guard ativados,
2. Windows Hello funcional e
3. VMware Workstation operando com VT‑x/EPT.

Você precisará decidir qual eixo — segurança, conveniência de login ou virtualização VMware — terá prioridade e aplicar a configuração correspondente. Use os procedimentos descritos aqui como roteiro, documente cada alteração e mantenha‑se atento às futuras atualizações de firmware e de build do Windows, pois a Microsoft pode otimizar essa coexistência em hardware Surface nas próximas versões.