Per analizzare minidump schermata blu Windows 11 servono i file .dmp generati dal sistema e uno strumento capace di interpretarli, come WinDbg. PowerShell permette di individuare il dump più recente, avviare l’analisi e isolare automaticamente codice BugCheck, modulo coinvolto e driver indicato da Windows. Il risultato non identifica sempre con certezza la causa del crash: la voce “Probably caused by” è un’ipotesi tecnica da verificare con simboli, data del driver e stack delle chiamate. La procedura seguente funziona con Windows 11 e consente di conservare un rapporto testuale consultabile.

Dove si trovano i minidump di Windows 11

Windows 11 salva normalmente i piccoli dump nella cartella C:WindowsMinidump. Ogni schermata blu genera, quando la configurazione è corretta, un file con estensione .dmp e un nome basato sulla data e sull’ora del blocco.

Per verificare la presenza dei file tramite PowerShell, apri Terminale Windows o PowerShell come amministratore ed esegui:

Get-ChildItem "$env:SystemRootMinidump" -Filter *.dmp |
Sort-Object LastWriteTime -Descending |
Select-Object Name, LastWriteTime, Length

Se la cartella è vuota, apri Impostazioni di sistema avanzate cercandole dal menu Start, quindi seleziona Avanzate > Avvio e ripristino > Impostazioni. In Scrittura delle informazioni di debug scegli Immagine della memoria ridotta (256 KB) e controlla che il percorso sia %SystemRoot%Minidump.

La generazione del minidump richiede anche un file di paging attivo sul volume di avvio. In Proprietà del sistema > Avanzate > Prestazioni > Impostazioni > Avanzate > Memoria virtuale, lascia preferibilmente attiva la gestione automatica delle dimensioni del file di paging, almeno durante la diagnosi.

Un minidump contiene soprattutto memoria del kernel, registri e informazioni sul thread che ha causato il blocco; non equivale al dump completo della memoria. Per questo motivo alcuni crash richiedono il file C:WindowsMEMORY.DMP, che può essere molto più grande.

Come installare WinDbg e analizzare un minidump con PowerShell

WinDbg è il debugger Microsoft adatto a leggere i file di dump di Windows. Puoi installarlo dal Microsoft Store cercando WinDbg, oppure tramite gli strumenti di debug del Windows SDK. Dopo l’installazione, verifica che il comando sia disponibile:

Get-Command windbg.exe -ErrorAction SilentlyContinue

Se PowerShell non trova windbg.exe, avvia WinDbg dal menu Start oppure indica manualmente il percorso dell’eseguibile, che nelle installazioni del Windows SDK si trova spesso in una cartella simile a C:Program Files (x86)Windows Kits10Debuggersx64windbg.exe. Il percorso può cambiare in base all’architettura e al metodo di installazione.

Il comando seguente seleziona il minidump più recente, configura il server dei simboli Microsoft, esegue !analyze -v e salva l’output in un file di testo:

$dump = Get-ChildItem "$env:SystemRootMinidump*.dmp" -ErrorAction Stop |
Sort-Object LastWriteTime -Descending |
Select-Object -First 1

$windbg = (Get-Command windbg.exe -ErrorAction Stop).Source
$comandi = '.symfix; .reload; !analyze -v; q'
$rapporto = & $windbg -z $dump.FullName -c $comandi 2>&1 |
Out-String

$rapporto | Set-Content "$env:USERPROFILEDesktopanalisi-minidump.txt"
$rapporto

.symfix imposta il percorso standard per i simboli di debug Microsoft, mentre .reload ricarica i simboli necessari. L’analisi può richiedere alcuni secondi e, al primo avvio, WinDbg può scaricare file dai server dei simboli. Il rapporto viene salvato sul desktop con il nome analisi-minidump.txt.

Per aprire il dump nell’interfaccia grafica puoi usare invece:

& $windbg -z $dump.FullName

Nella finestra di WinDbg inserisci il comando seguente nella console in basso:

.symfix
.reload
!analyze -v

La riga BugCheck mostra il codice della schermata blu, mentre Probably caused by indica il modulo che WinDbg considera più probabile. Le righe MODULE_NAME e IMAGE_NAME aiutano a collegare il modulo a un file, spesso con estensione .sys.

Come estrarre codice BugCheck e driver sospetto dal rapporto

PowerShell può estrarre le righe più importanti senza rileggere manualmente l’intero rapporto. Lo script seguente cerca le sezioni normalmente prodotte da !analyze -v:

$righeInteressanti = $rapporto -split "`r?`n" |
Where-Object {
$_ -match 'BugCheck|BUGCHECK_CODE|Probably caused by|MODULE_NAME|IMAGE_NAME|FAILURE_BUCKET_ID'
}

$righeInteressanti

Per ottenere valori separati, usa espressioni regolari tolleranti alle differenze di formattazione tra versioni di WinDbg:

$bugcheck = [regex]::Match(
$rapporto,
'(?im)BUGCHECK_CODE:s*(0x?[0-9a-f]+)'
).Groups[1].Value

$causa = [regex]::Match(
$rapporto,
'(?im)Probably caused bys*:s*(.+)'
).Groups[1].Value.Trim()

$modulo = [regex]::Match(
$rapporto,
'(?im)MODULE_NAME:s*(.+)'
).Groups[1].Value.Trim()

$immagine = [regex]::Match(
$rapporto,
'(?im)IMAGE_NAME:s*(.+)'
).Groups[1].Value.Trim()

[pscustomobject]@{
Dump              = $dump.FullName
BugCheck          = $bugcheck
ProbablyCausedBy  = $causa
ModuleName        = $modulo
ImageName         = $immagine
}

Il campo ProbablyCausedBy non rappresenta una prova definitiva. Un driver di rete, grafico, archiviazione o sicurezza può apparire nello stack perché ha interagito con il componente realmente responsabile del crash. Per valutare il sospetto, confronta il nome del file .sys con il produttore, la versione e la data del driver installato.

Per ottenere maggiori dettagli su un modulo specifico, usa il comando lmvm nella console di WinDbg, sostituendo nome_modulo con il valore indicato da MODULE_NAME:

lmvm nome_modulo

L’output può contenere percorso, timestamp, versione, società e nome descrittivo del driver. Un timestamp molto vecchio non dimostra da solo che il driver sia difettoso, ma segnala che è opportuno installare una versione compatibile dal sito del produttore dell’hardware o del software.

Come confermare la causa senza affidarsi a un solo campo

Per analizzare minidump schermata blu Windows 11 in modo affidabile, esamina anche lo stack e il contesto del thread. In WinDbg, i comandi più utili dopo !analyze -v sono:

kv
lm
!thread

kv visualizza lo stack con gli argomenti delle chiamate, lm elenca i moduli caricati e !thread mostra il thread corrente. Se più dump riportano lo stesso file .sys, lo stesso FAILURE_BUCKET_ID o lo stesso codice BugCheck, il sospetto diventa più consistente, ma resta necessario verificare aggiornamenti, firmware e compatibilità.

Windows 11 registra spesso anche l’evento BugCheck, con ID evento 1001, nel registro Sistema. PowerShell può filtrare gli eventi recenti:

Get-WinEvent -FilterHashtable @{
LogName = 'System'
Id      = 1001
} -MaxEvents 10 |
Select-Object TimeCreated, ProviderName, Message

Per testare un driver non basta aggiornare casualmente tutti i componenti. Driver Verifier può forzare controlli più severi, ma può provocare nuovi arresti intenzionali e deve essere usato solo dopo aver creato un punto di ripristino o un backup. Per controllare un driver specifico:

verifier /standard /driver nome.sys

Dopo il riavvio, se il sistema diventa instabile, entra in modalità provvisoria e disattiva il controllo con:

verifier /reset

Aggiorna il driver sospetto usando Windows Update o il sito ufficiale del produttore, evitando pacchetti provenienti da raccolte non verificate. Se il problema è iniziato subito dopo un aggiornamento, la disinstallazione del driver o il ripristino della versione precedente può essere più indicato dell’installazione di una versione generica.

L’analisi dei minidump diventa utile quando codice BugCheck, modulo sospetto, stack e cronologia degli aggiornamenti indicano la stessa area del sistema. Con PowerShell e WinDbg puoi analizzare minidump schermata blu Windows 11 e conservare prove tecniche invece di basarti soltanto sul messaggio mostrato dalla schermata blu.

FAQ

PowerShell può individuare, copiare e filtrare il rapporto prodotto da WinDbg, ma non interpreta autonomamente la struttura interna di un minidump. Per la decodifica servono WinDbg o strumenti equivalenti.

No. La voce indica l’ipotesi principale dell’analisi !analyze -v, ma può riferirsi a un driver coinvolto indirettamente. Stack, simboli, ripetizione nei dump e versione del driver devono confermare il sospetto.

La causa può essere una configurazione errata dei dump, l’assenza di un file di paging sul volume di avvio, spazio insufficiente o un arresto troppo improvviso per completare la scrittura. Controlla le impostazioni di Avvio e ripristino.

Driver Verifier è uno strumento diagnostico avanzato che può causare schermate blu durante il test. Attivalo solo per driver specifici e usa verifier /reset per disabilitarlo se Windows diventa instabile.

Il comando lmvm nome_modulo mostra informazioni come percorso, versione, produttore e timestamp del modulo caricato.

Altri articoli di questa serie: