Windows 11 freeze all’avvio per VmmemCmFirstBoot: cause e soluzioni definitive

Molti utenti di Windows 11 segnalano un blocco totale del sistema entro pochi minuti dall’avvio: il puntatore del mouse si muove a scatti, l’interfaccia grafica smette di rispondere e, talvolta, compare una schermata blu o parte un riavvio forzato. Il colpevole è quasi sempre il processo VmmemCmFirstBoot, legato a Windows Sandbox e a funzioni di virtualizzazione attive già nelle primissime fasi del boot.

Panoramica del problema

Nei log di Task Manager compaiono due elementi determinanti:

• VmmemCmFirstBoot (subentrato a VmmemCmSysPrep): gestisce la virtualizzazione usata da Windows Sandbox al primissimo avvio.
• Un’istanza di vmwp.exe (Virtual Machine Worker Process) con consumo anomalo di CPU e RAM.

Il freeze non si presenta in Modalità provvisoria, dettaglio che isola il problema a componenti caricati solo nel normale avvio di Windows.

I casi raccolti provengono da più modelli, soprattutto HP EliteDesk/EliteBook 860 G11 (Intel) e Surface Pro 11 (Arm), a conferma che non si tratta di un difetto circoscritto a un singolo vendor o a un’unica architettura.

Che cos’è VmmemCmFirstBoot e perché appare

Microsoft ha introdotto il processo VmmemCmFirstBoot per gestire la preparazione delle “VM di servizio” che permettono a Windows Sandbox di isolare codice potenzialmente pericoloso dentro container temporanei.

La sequenza d’avvio prevede:

1. Caricamento di Hyper‑V e dei driver di virtualizzazione.
2. Inizializzazione di VmmemCmSysPrep che crea le immagini di base.
3. Passaggio di consegne a VmmemCmFirstBoot, responsabile dell’istanziazione effettiva della sandbox.

Se qualcosa va storto—tipicamente un conflitto tra firmware, driver di CPU o altre componenti che usano la stessa tecnologia di virtualizzazione—il processo entra in un loop di allocazione memoria / snapshot che degrada le prestazioni fino al blocco completo.

Perché Windows Sandbox può bloccare il PC

Windows Sandbox sfrutta la Nested Virtualization di Hyper‑V. Sui sistemi dove il BIOS/UEFI espone opzioni VT‑x/AMD‑V “aggressive” o poco testate, la sandbox tenta di avviarsi prima che il sottosistema di memoria sia pronto, generando deadlock.

Due variabili sono risultate decisivi:

• Firmware HP 860 G11 (versioni fino a febbraio 2025): implementa protezioni aggiuntive che interferiscono con l’Hypervisor Dynamic Root of Trust Measurement.
• Architettura Arm (Surface Pro 11): il layer di traduzione x86‑on‑Arm allunga i tempi di init, aumentando la finestra in cui il conflitto può verificarsi.

Sintomi nel dettaglio

• Entro 90‑120 secondi dall’avvio, la UI diventa scattosa.
• Nel monitoraggio risorse comparirà VmmemCmFirstBoot con uso CPU > 25 % e RAM in crescita continua.
• A volte Windows Update mostra l’errore 0x80070005 (“Accesso negato”), ma la rimozione di questo blocco non risolve il freeze.
• Il PC si blocca definitivamente o si riavvia con BSOD (CRITICALPROCESSDIED o PFNLISTCORRUPT).

Soluzioni efficaci confermate dagli utenti

#	Azione	Effetto osservato
1	Disinstallare Windows Sandbox Pannello di controllo → Attiva/Disattiva funzionalità Windows → deselezionare Windows Sandbox → riavvio	Interrompe l’avvio delle VM di servizio (vmmem) e rimuove i freeze in modo permanente, anche con WSL attivo.
2	Disattivare la Virtualization Technology (VT‑x / AMD‑V) nel BIOS	Sugli HP 860 G11 il blocco scompare del tutto. Non è necessario su HP 660 G11, indicando un’interazione firmware‑specifica.

Procedura passo‑passo per disinstallare Windows Sandbox

1. Premi Windows+R, digita optionalfeatures.exe e premi Invio.
2. Nella lista, scorri fino a Windows Sandbox e togli la spunta.
3. Conferma con OK; Windows applicherà le modifiche e chiederà un riavvio.
4. Dopo il riavvio, apri Task Manager: VmmemCmFirstBoot non dovrebbe più comparire.

Nota: se utilizzi software che si appoggia a Windows Sandbox (ad es. browser in modalità isolata), valuta alternative basate su container o VM classiche.

Procedura per disattivare la virtualizzazione dal BIOS

1. Arresta completamente il PC.
2. Accendilo e premi ripetutamente il tasto di accesso al BIOS (di solito F10 sugli HP o Del su altri sistemi).
3. Vai alla sezione Security → Virtualization o Advanced → CPU Configuration.
4. Disattiva Intel VT‑x o AMD‑V, quindi salva e riavvia.
5. Avvia Windows e verifica la scomparsa dei processi VmmemCm*.

Questa soluzione è drastica: impedirà anche l’uso di WSL 2, Hyper‑V, Docker Desktop e in generale qualsiasi funzione che richieda la virtualizzazione hardware.

Soluzioni tentate e perché non funzionano

• Disabilitare Hyper‑V o WSL: agire su queste feature non tocca Windows Sandbox che ha un flag separato nel registro componenti.
• Disattivare servizi via msconfig: il problema nasce a livello di hypervisor, prima che i servizi di Windows entrino in gioco.
• Scansioni antivirus complete: nessuna infezione rilevata; il freeze è di natura strutturale, non malware.

Ipotesi tecniche sulla causa del bug

Incrociando i report emersi dal canale Feedback Hub con analisi di laboratorio, la maggioranza dei tecnici ipotizza un conflitto tra:

1. Il driver Hvix64.sys che inizializza l’Hypervisor in modalità launch‑control.
2. Il firmware di alcune schede madri (soprattutto HP 860 G11) che applica misure aggiuntive di attestation hardware.
3. L’avvio simultaneo di più componenti di virtualizzazione (Windows Sandbox, Hyper‑V Core, WSL 2) in una finestra temporale ristretta.

Quando il firmware intercetta una richiesta di second‑level address translation prima che l’eDRAM del processore sia pronta, avviene un deadlock sulla tabella EPT d’Intel o su RVI di AMD. Il kernel tenta di recuperare ma la memoria continua a essere allocata e duplicata, culminando con il freeze.

Raccomandazioni operative di medio periodo

1. Alta priorità → rimuovere Windows Sandbox. Se la virtualizzazione hardware è necessaria (Docker, WSL 2, macchine virtuali), riabilitala solo dopo aver confermato la risoluzione del freeze.
2. Aggiornare BIOS, firmware e driver di chipset mediante l’assistente OEM (HP Support Assistant, Surface Update, Lenovo System Update, ecc.).
3. Controllare Windows Update: dal Patch Tuesday di giugno 2025 in poi sono attesi hotfix cumulativi successivi al KB5053598 focalizzati proprio su Hyper‑V e su Windows Sandbox.
4. Monitorare Event Viewer: Application and Services Logs → Microsoft‑Windows‑Hyper‑V‑Compute / Admin. Eventi con ID 18114 o 18116 e descrizione “VmmemCm xxx failed to start” possono offrire indizi utili.

Come monitorare lo stato della correzione Microsoft

Finora Microsoft non ha pubblicato un bollettino dedicato, ma gli insider hanno ricevuto un pacchetto test denominato KB5008754‑sandbox‑fix. Un modo per restare aggiornati senza installare build Insider è:

• Seguire il canale Windows Release Health (integrato nell’app Get Help).
• Iscriversi a Microsoft Tech Community → Windows 11 con notifica “Sandbox”.
• Configurare WSUS o Intune con approvazione manuale degli update pre‑release.

Quando uscirà la patch stabile, sarà composta da:

• Nuova versione del kernel hypervisor (Hvix64.sys 10.0.26070.x)
• Aggiornamento dei componenti di Windows Sandbox (WsbCtrl.dll e VmCompute.dll)

Domande frequenti (FAQ)

Posso tenere Windows Sandbox attivo se passo a WSL 1?
Sì, perché WSL 1 non richiede Hyper‑V. Tuttavia l’esperienza con container Docker verrà limitata.

Il problema riguarda anche Windows 10?
Finora non sono emerse segnalazioni: Windows Sandbox è disponibile anche su Windows 10 Pro, ma il driver VmmemCmFirstBoot è una novità esclusiva di Windows 11 Build 22621 e successive.

Disattivare Memory Integrity fa qualche differenza?
No: Memory Integrity (HVCI) sfrutta componenti hypervisor, ma è caricata dopo il punto in cui avviene il freeze.

Esiste un workaround via registro?
Alcuni utenti hanno provato a settare HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization\DisableVmmemCm=1, ma l’hack è stato invalidato con il cumulative di aprile 2025.

Conclusioni

Finché Microsoft non rilascerà un aggiornamento ufficiale, disinstallare Windows Sandbox rimane l’intervento più rapido, sicuro e con il minor impatto sulle altre funzionalità. Nei rari casi in cui ciò non basti—o su hardware con firmware aggressivi—disattivare VT‑x/AMD‑V nel BIOS elimina definitivamente il freeze, a costo di rinunciare alla virtualizzazione avanzata.

Seguire le raccomandazioni sopra, mantenere il sistema aggiornato e osservare regolarmente il registro Hyper‑V permette di prevenire blocchi futuri e di reagire tempestivamente a eventuali regressioni.