Errore BSoD processo critico su Windows 11 e 10: come risolverlo

Quando Windows si ferma su “processo critico”

La schermata blu con errore legato a un processo critico non è un messaggio generico da ignorare: Windows ha rilevato che un componente fondamentale del sistema operativo si è chiuso, è andato in crash o ha perso una dipendenza essenziale. In pratica non stai guardando un semplice problema dell’applicazione aperta in quel momento, ma un segnale che coinvolge il kernel, un driver, il file system, il disco, oppure la catena di avvio di un servizio di sistema.

Su Windows 10 e Windows 11 la logica è la stessa: il sistema protegge l’integrità del kernel e, quando trova una condizione irreversibile, forza il blocco. Il risultato può comparire come BSOD con codici tipo CRITICAL_PROCESS_DIED o CRITICAL_STRUCTURE_CORRUPTION, ma il sintomo pratico è sempre quello: riavvio improvviso, perdita di lavoro e, se il problema si ripete, una macchina che diventa instabile anche dopo il boot.

La cosa utile da fare non è partire a caso con “ripara tutto” o reinstallare subito. Prima si capisce quale layer ha rotto: avvio, storage, driver, integrità file, aggiornamenti recenti o corruzione del profilo. Se salti questa parte, rischi di mascherare il problema per qualche ora e ritrovarti nello stesso punto al riavvio successivo.

Il modello corretto: dal sintomo al layer guasto

Il primo errore è trattare tutte le BSOD allo stesso modo. Qui serve una lettura a strati:

• Boot e servizi di sistema: il crash avviene durante il login, subito dopo il desktop o in fase di avvio.
• Driver: il problema emerge dopo aggiornamenti di GPU, storage, chipset, antivirus o software di virtualizzazione.
• Storage e file system: il sistema mostra lentezza, freeze, errori di lettura, eventi disco o file corrotti.
• Integrità Windows: componenti di sistema danneggiati, aggiornamenti interrotti, file essenziali mancanti.
• RAM o hardware: riavvii casuali, BSOD diversi, errori WHEA, crash anche in modalità provvisoria.

Se vuoi lavorare in modo pulito, ragiona così: atteso = Windows parte e resta stabile; osservato = BSOD ricorrente con processo critico, spesso dopo login o durante operazioni di I/O. Da lì costruisci ipotesi ordinate per probabilità e le falsifichi velocemente.

Le tre ipotesi più probabili, in ordine pratico

1. Driver o filtro kernel difettoso. È la causa più frequente quando il problema è iniziato dopo un update, un nuovo software di sicurezza, un tool di backup o un driver storage/GPU. Si falsifica in pochi minuti avviando in modalità provvisoria e verificando se la BSOD sparisce.
2. Corruzione di file di sistema o aggiornamento incompleto. Se Windows è stato spento male, ha perso alimentazione o un aggiornamento si è interrotto, un componente critico può diventare incoerente. Si falsifica controllando i log eventi e l’integrità con gli strumenti di sistema.
3. Problema di disco o RAM. Se il crash è casuale, compare anche in fase di ripristino o cambia codice nel tempo, la probabilità di un guasto hardware cresce. Si falsifica con test memoria e controlli SMART/diagnostica disco.

La regola è semplice: prima osserva, poi modifica. Non disinstallare a tappeto tutto quello che trovi. Ogni azione deve avere un rollback chiaro.

Raccolta evidenze: cosa guardare prima di toccare il sistema

Prima di fare cambiamenti, raccogli almeno questi elementi:

• Codice esatto della BSOD e momento in cui si presenta: durante il login, dopo il desktop, in idle, durante copia file, dopo update.
• Event Viewer: apri eventvwr.msc e controlla Windows Logs e System, cercando errori di BugCheck, Disk, Ntfs, WHEA-Logger, Service Control Manager.
• Reliability Monitor: esegui perfmon /rel e verifica se il primo errore coincide con un driver, un update o un’applicazione installata di recente.
• Minidump: cerca in C:\Windows\Minidump\ i file .dmp. Se presenti, indicano che c’è abbastanza materiale per un’analisi più precisa.

Se hai accesso al dump, puoi usare strumenti come WinDbg per capire il modulo coinvolto. Se non hai il dump, non inventare la causa: il gap va chiuso prima con i log, non con ipotesi creative.

Intervento minimo e reversibile: partire dalla modalità provvisoria

La prima mossa utile, perché reversibile e a basso rischio, è avviare Windows in modalità provvisoria. L’obiettivo non è “riparare” subito, ma verificare se il sistema resta stabile con driver e servizi ridotti.

1. Apri il menu di avvio avanzato. Se Windows si avvia ancora per poco, usa Impostazioni > Sistema > Ripristino > Avvio avanzato.
2. Se non arrivi al desktop, forza l’ambiente di ripristino interrompendo l’avvio per più volte o usa un supporto di installazione Windows.
3. Seleziona Modalità provvisoria o Modalità provvisoria con rete solo se ti serve scaricare tool o consultare documentazione.
4. Verifica se la BSOD si ripresenta. Se sparisce, il problema è molto probabilmente legato a driver, servizio terzo o software residente.

Blast radius: limitato alla sessione di avvio. Rollback: riavvio normale o disattivazione del flag di avvio provvisorio. Se in modalità provvisoria il sistema resta stabile, non hai ancora risolto: hai solo ristretto il campo.

Controllo dell’integrità: file di sistema e immagine Windows

Se il sistema avvia, il passo successivo è verificare l’integrità dei componenti Windows. Qui non si parla di “ottimizzazione”, ma di riparazione coerente.

sfc /scannow

Questo comando controlla i file protetti di sistema. Se trova corruzioni e le corregge, hai un indizio forte sulla natura del problema. Se fallisce o segnala file non riparabili, passa al controllo dell’immagine:

DISM /Online /Cleanup-Image /RestoreHealth

Prima di eseguire DISM, verifica che Windows Update o la sorgente di riparazione siano disponibili. Se la macchina è isolata o Windows Update è rotto, potresti dover indicare una sorgente locale. L’artefatto da osservare è il log di output del comando: cerca messaggi di successo, file riparati o errori di accesso alla sorgente.

Se dopo SFC e DISM la BSOD non si presenta più, il problema probabilmente era una corruzione dei componenti di sistema. Se invece torna, non insistere con gli stessi comandi: serve un controllo su driver e storage.

Driver: il punto dove spesso si nasconde il colpevole

Un driver difettoso può causare crash di processo critico senza lasciare un colpevole ovvio. I casi più comuni riguardano storage, controller NVMe/SATA, GPU, antivirus con filtro kernel, software di cifratura, virtualizzazione e tool di backup che installano driver propri.

La verifica pratica è questa:

1. Apri Gestione dispositivi e cerca dispositivi con warning, aggiornamenti recenti o rollback possibili.
2. Controlla in Impostazioni > Windows Update > Cronologia aggiornamenti se il problema è iniziato dopo un driver distribuito via update.
3. Se hai installato software di terze parti poco prima del problema, valuta la disinstallazione temporanea partendo da antivirus non Microsoft, agent di backup, utility RGB, tool di tuning o suite per storage.

Se il sospetto è forte ma vuoi tenere basso il rischio, fai un rollback del singolo driver invece di rimuovere mezzi componenti del sistema. Il principio è: un cambiamento alla volta, poi verifica. Se la BSOD sparisce, hai trovato il ramo da approfondire.

Disco e file system: quando il problema è a valle, non a monte

Se il sistema è lento, fa freeze o mostra errori di lettura, il disco va controllato subito. Una corruzione del file system o un SSD/HDD degradato può produrre proprio crash apparentemente “di processo”, perché il servizio critico non riesce più a leggere i dati necessari.

Controlli utili:

• SMART con tool del produttore o utility affidabili, per verificare stato salute, settori riallocati, errori di lettura e ore di utilizzo.
• CHKDSK su volume di sistema, ma con criterio: se ci sono segnali di guasto fisico, prima salva i dati importanti. Un controllo aggressivo non è la prima mossa su un disco già instabile.
• Event Viewer per errori Disk, Ntfs, storahci, iaStor o equivalenti del controller.

Se trovi errori di storage, il fix strutturale non è “riparare Windows”, ma mettere in sicurezza i dati e sostituire il supporto se i segnali puntano al guasto hardware. Qui il rollback non esiste: il punto è non peggiorare la situazione.

Memoria e hardware: quando la BSOD cambia faccia

Se il codice della schermata blu cambia, compare in momenti casuali o non sparisce neppure dopo i controlli software, il sospetto si sposta su RAM o hardware di base. In quel caso un test memoria è obbligatorio.

Usa Diagnostica memoria Windows o, meglio ancora, un test più approfondito come MemTest86. L’obiettivo non è “fare un giro e basta”, ma cercare errori ripetibili. Se emergono errori, il problema non è più di Windows: è del sottosistema memoria, del banco difettoso, dello slot o del profilo XMP/EXPO troppo spinto.

Se il PC è stato assemblato o aggiornato di recente, valuta anche BIOS/UEFI e impostazioni di stabilità. Un profilo RAM aggressivo può funzionare per giorni e poi crollare sotto carico. In quel caso, la correzione minima è riportare le impostazioni memoria a valori standard e verificare la stabilità prima di qualsiasi overclock o tuning.

Ripristino, aggiornamenti e punto di non ritorno

Se il problema è iniziato dopo un aggiornamento Windows, dopo un driver distribuito dal sistema o dopo una modifica recente, hai tre strade con impatto diverso:

1. Disinstallare l’ultimo aggiornamento qualitativo, se la correlazione temporale è stretta.
2. Ripristinare il driver o rimuovere il software introdotto prima del crash.
3. Ripristino configurazione di sistema, se era già attivo e hai un punto precedente al guasto.

Questo non è un atto di fede: è una strategia di rollback. La verifica è semplice: dopo il rollback, il sistema deve avviarsi e rimanere stabile per un ciclo d’uso realistico, non per trenta secondi. Se il problema torna, la causa non era solo l’ultimo cambiamento.

Quando conviene fermarsi e salvare i dati

Ci sono casi in cui la priorità non è “far tornare Windows”, ma non perdere dati. Se la BSOD è accompagnata da errori disco, il sistema non vede più il volume o il desktop non si carica, evita esperimenti pesanti. Copia prima i dati essenziali da ambiente di ripristino o con un supporto esterno, poi fai diagnostica più aggressiva.

Se il volume di sistema è cifrato, verifica che tu abbia le chiavi o il metodo corretto di sblocco prima di qualsiasi operazione. Qui il problema non è tecnico in astratto: è operativo. Senza credenziali o recovery key, il recupero può diventare impossibile.

Una sequenza pratica che funziona nella maggior parte dei casi

1. Raccogli il codice BSOD, il momento del crash e i log in Event Viewer e Reliability Monitor.
2. Avvia in modalità provvisoria per capire se il problema è legato a driver o servizi terzi.
3. Esegui sfc /scannow e, se serve, DISM /Online /Cleanup-Image /RestoreHealth.
4. Controlla update recenti, driver e software installati poco prima del crash.
5. Verifica storage e RAM se i sintomi indicano instabilità hardware.
6. Solo dopo, valuta rollback, ripristino o reinstallazione pulita.

Questa sequenza riduce il rischio di fare danni e ti porta più vicino alla causa reale. Non è la via più “rapida” in senso marketing, ma è quella che evita di trasformare un crash isolato in una reinstallazione inutile.

Errore tipico da evitare

Se il sistema va in BSOD con processo critico, non partire da tool di “pulizia”, driver booster, registry cleaner o ottimizzatori vari. Prima osserva, poi ripara. Altrimenti stai aggiungendo rumore sopra a un guasto già abbastanza chiaro.

Un’altra scorciatoia sbagliata è formattare subito. La reinstallazione risolve il sintomo, non sempre la causa. Se il disco è degradato o la RAM è instabile, il problema riappare anche su un’installazione fresca.

Chiusura operativa

La BSOD “processo critico” su Windows 10 e 11 va trattata come un incidente di stabilità, non come un semplice errore grafico. Il percorso serio è sempre lo stesso: capire il layer coinvolto, leggere i log, ridurre la superficie con modalità provvisoria, verificare integrità file e immagine, poi concentrarsi su driver, storage e memoria. Solo dopo ha senso parlare di ripristino o reinstallazione.

Assunzione: i comandi e i percorsi indicati sono validi per installazioni Windows recenti con accesso amministrativo locale; se la macchina è gestita da policy aziendali, i rollback e la rimozione driver possono essere limitati da criteri di dominio o MDM.