Se o seu PC com Windows 11 24H2 trava logo após aparecer a Área de Trabalho e você percebe que o processo VmmemCmFirstBoot ou VmmemCmSysPrep dispara o uso de CPU e memória, provavelmente o culpado é o Windows Sandbox em conflito com a virtualização do sistema. Entenda o que está acontecendo e veja como resolver em definitivo.
Visão geral do problema
Desde as compilações preliminares da versão 24H2, diversos usuários—especialmente proprietários de estações HP EliteDesk, notebooks EliteBook 860 G11 e equipamentos ARM—relataram congelamentos imediatos após a inicialização. A telemetria do Gerenciador de Tarefas exibe um pico instantâneo em vmmem (com os sub‑processos VmmemCmFirstBoot ou VmmemCmSysPrep), resultado em bloqueio total do cursor, eventual “tela azul” ou reinicialização forçada.
Sintomas detalhados
- Trava logo após o boot: em 5 – 30 s, o ponteiro do mouse começa a saltar, a ventoinha acelera e a máquina para de responder.
- Uso anormal de recursos:
vmmemconsome 100 % de um ou mais núcleos e aloca vários GB de RAM. - Erro no Windows Update: KB5053598 falha com código 0x80070005 em alguns sistemas, mas não é a raiz do problema.
- Modo de Segurança opera normalmente: não há travamento porque o Hyper‑V é desativado nesse modo.
- Encerrar um
vmwp.exe“salva” a sessão: matando o processo do Virtual Machine Worker Process associado ao Sandbox, o sistema volta a responder—indício claro de falha na camada de virtualização.
Causa técnica por trás do VmmemCmFirstBoot
O Windows Sandbox cria uma pequena máquina virtual isolada sempre que você o inicia. Nos bastidores, o Container Manager (VmmemCm*) dispara uma sequência de primeira inicialização (first‑boot) para selar a imagem do contêiner. Em determinadas combinações de firmware e drivers—por exemplo, BIOS com VT‑x/AMD‑V ativo, Secure Boot customizado, WSL 2 instalado ou outro hipervisor de terceiros—essa sequência entra em loop.
O ciclo infinito prende o vmwp.exe, que tenta reiniciar a VM da Sandbox, criando novas instâncias de vmmem em cascata. Como o processo roda em modo privilegiado, o sistema operacional principal não consegue preemptar a execução, levando ao congelamento geral ou a erros de verificação de segurança (bugcheck).
Soluções confirmadas
Três medidas foram testadas pela comunidade e por equipes de TI corporativas. A tabela a seguir resume efeitos e impactos:
| Medida | Efeito observado | Impacto / Observações |
|---|---|---|
| Desativar ou remover Windows Sandbox (Painel de Controle → Programas → Ativar ou desativar recursos do Windows) | Elimina o processo vmmem* no arranque; sistema volta a funcionar normalmente. | Mantém WSL 2 operante; solução simples e definitiva na maioria dos cenários. |
| Desligar “Virtualization Technology (VT‑x/AMD‑V)” no BIOS/UEFI | PC inicia sem travar mesmo com Sandbox instalado. | Perde‑se suporte a VMs/WSL; usado como mitigação em ambientes HP 860 G11 onde virtualização não era exigida. |
Matar rapidamente o processo vmwp.exe da Sandbox via Gerenciador de Tarefas | Evita o freeze na sessão atual. | Paliativo; exige intervenção manual a cada boot ou script de inicialização. |
Desativar o Windows Sandbox (recomendado)
A remoção do recurso impede que o Container Manager seja chamado na fase de pré‑login, eliminando a condição de corrida. Você continua podendo usar WSL 1/2, Docker Desktop (em modo WSL) e outros softwares que dependem do Hyper‑V.
Desligar VT‑x/AMD‑V (alternativa de emergência)
Indicado quando a política corporativa exige manter o Sandbox instalado, mas não há necessidade de virtualizar outros SOs. Lembre‑se de que recursos como VBS (Virtualization‑Based Security) e Credential Guard também requerem extensões de virtualização; ao desativá‑las você reduz a superfície de ataque, porém perde camadas de proteção.
Encerrar o vmwp.exe (paliativo)
Algumas empresas automatizaram um script de logon que localiza instâncias de vmwp.exe cujo command line contenha “VmmemCm” e as finaliza. A tática “ganha tempo” enquanto se aguarda patch oficial, mas não cobre cenários sem login (por exemplo, quiosques).
Procedimentos passo a passo
Removendo o Windows Sandbox
- Pressione Win + R, digite optionalfeatures.exe e clique em OK.
- Na lista, desmarque Windows Sandbox.
- Clique em OK e permita que o sistema realize as alterações; reinicie quando solicitado.
- Após o reboot, confirme no Gerenciador de Tarefas que o
vmmemnão aparece até abrir o WSL 2 ou outra VM.
Desativando a virtualização no BIOS/UEFI
- Reinicie o PC e entre na interface UEFI (geralmente Esc, Del ou F2).
- Navegue até Advanced → CPU Configuration ou equivalente.
- Localize Intel VT‑x, AMD‑V ou SMV; selecione Disabled.
- Salve e reinicie. O Windows arrancará sem hipervisor; o Sandbox não irá inicializar automaticamente.
Automatizando o kill do vmwp.exe
Crie um arquivo .bat na pasta Inicializar do menu Iniciar:
@echo off
for /f "tokens=2" %%i in ('tasklist /FI "IMAGENAME eq vmwp.exe" /v ^| findstr VmmemCm') do taskkill /PID %%i /F
Embora funcione, trate como solução temporária: qualquer atraso no script pode permitir que o loop consuma recursos antes do encerramento.
Boas práticas de prevenção
- Mantenha BIOS/UEFI, drivers de chipset e firmware do TPM atualizados—muitas placas recebem microcódigos que refinam as instruções de virtualização.
- Prefira WSL 2 ao Hyper‑V integral sempre que possível; a sobreposição de múltiplos hipervisores aumenta o risco de deadlocks.
- Use Windows Insider Preview apenas em máquinas de teste: os builds Dev/Beta podem introduzir regressões como essa.
- Crie pontos de restauração ou imagens WIM antes de habilitar recursos como Sandbox, Device Guard ou Windows Subsystem for Android.
Perguntas frequentes (FAQ)
Desativar o Sandbox afeta a segurança?
O Windows Sandbox é útil para executar softwares suspeitos em um ambiente descartável, mas não é componente obrigatório do sistema. Antivírus, SmartScreen e VBS permanecem ativos.
Posso simplesmente desinstalar o WSL?
Não é necessário. O conflito primário ocorre dentro do Container Manager da Sandbox. WSL sozinho raramente gera congelamentos, desde que o hypervisor não esteja corrompido.
Existe patch oficial?
A Microsoft reconheceu o bug no Feedback Hub e trabalha em correção cumulativa prevista para o canal Release Preview. Usuários corporativos podem acompanhar o ID 44899845 no portal MSRC.
É seguro reativar tudo após a correção?
Sim. Quando o patch estiver instalado, reabilite o suporte a VT‑x/AMD‑V no firmware, depois ative novamente o Windows Sandbox. Teste por alguns reboots antes de liberar em larga escala.
Conclusão
O sintoma clássico—VmmemCmFirstBoot monopolizando recursos até o congelamento—não deriva de hardware defeituoso, mas de um conflito entre o Windows Sandbox e a cadeia de virtualização. Desativar o recurso é a saída mais rápida e limpa, preservando WSL, Docker e demais utilitários. Caso precise manter o Sandbox, desligue a tecnologia de virtualização em firmware ou automatize o encerramento do vmwp.exe até a chegada da correção oficial.
Resumo em uma linha: se o Windows 11 trava logo após o boot e você vê VmmemCmFirstBoot, desative a Windows Sandbox; se necessário, desligue a virtualização no BIOS até a Microsoft publicar uma atualização definitiva.