NOTA: le risorse elencate nelle sezioni "Risorse della Community" e "Vedere anche" ed i software indicati nel presente articolo sono disponibili solo in lingua Inglese.
Per gli articoli della Microsoft Knowledge Base è disponibile un sistema di traduzione automatica.

---

Perchè si verifica un crash di Windows?

Un crash di Windows (ovvero l'arresto dell'esecuzione del sistema e la visualizzazione della schermata blu) può verificarsi per diverse ragioni: un riferimento ad in indirizzo di memoria che causa una violazione di accesso, un'eccezione inattesa, un driver difettoso in modalità kernel e così via. E' importante capire che Windows potrebbe potrebbe continuare a funzionare anche in presenza di problemi seri, isolare l'errore e cercare di ripristinarsi in qualche modo: ma il problema individuato potrebbe essere causto da un errore ben più serio ed in profondità che potrebbe provocare ulteriori eccezioni durante lo svolgimento dell'elaborazione e che potrebbero, infine, portare alla corruzione dei dati nella memoria RAM o sul disco. Ovviamente, questo è inaccettabile, quindi Windows adotta una sorta di "politica di fallimento, sicuro e veloce" che consiste nell'arrestare l'esecuzione, impostare una modalità VGA a bassa risoluzione per il video, dipingere uno sfondo blu, scrivere in un file (il file di dump) lo stato della memoria e le informazioni sul crash e visualizzare un codice di stop contenente un messaggio ed alcune indicazioni per l'utente. "Blue Screen Of Death", "Bugcheck" e "Stop errors" sono parole differenti utilizzate per rappresentare lo stesso tipo di eccezione non gestita durante l'esecuzione in modalità kernel e che causa l'arresto del sistema (ed il possibile riavvio). La causa del problema può essere qualsiasi cosa da una fluttuazione nell'alimentazione del sistema ad un componente danneggiato o ad un bug software/hardware.
In Windows 7 e nelle versioni precedenti, la BSOD ha il seguente aspetto

Figura 1: la schermata blu "attuale".

mentre nella Developer Preview di Windows 8 ha il seguente aspetto (un po' meno "spaventoso" del precedente)

Figura 2: la "futura" (?) schermata blu.

E' interessante osservare la distribuzione dei bugcheck rispetto alle loro cause: il libro "Windows Internals, 5th Edition" riporta il seguente grafico che visualizza la distribuzione delle categorie degli errori in Windows Vista SP1 rilevate a Settembre 2008.

Figura 3: distribuzione delle categorie di errore.

↑ Torna all'inizio

Terminologia di base

Blue screen: quando nel sistema si verifica un problema hardware, un'inconsistenza nei dati o qualcos'altro di simile, può essere visualizzata una schermata blu contenente informazioni che possono essere utilizzata per determinare la causa dell'errore. Queste informazioni comprendono il codice di STOP e l'indicazione della creazione del file di dump. Può anche comprendere una lista dei drivers caricati ed un trace dello stack.
Crash dump file: è possibile configurare il sistema affinchè registri le informazioni in un file di dump del crash sul proprio hard disk ogni volta in cui viene generato un codice di STOP. Il file (denominato memory.dmp) contiene informazioni che il debugger può utilizzare per analizzare l'errore. Questo file può avere dimensioni pari al quantitativo di memoria fisica installata nel computer. Per impostazionie predefinita, il file viene registrato nella cartella Windows\Minidump.
Debugger: un programma creato per individuare, trovare e correggere errori in un altro programma. Permette all'utente di avanzare all'interno del processo in esecuzione e dei suoi threads, monitorando la memoria, le variabili ed altri elementi del contesto del processo e del thread .
Kernel mode: la modalità del processore in cui sono eseguiti i servizi di sistema ed i device drivers. In questa modalità sono disponibili tutte le interfacce e le istruzioni della CPU e l'intera memoria è accessibile.
Minidump file: un minidump è una versione più piccola di un file di dump completo o della memoria del kernel. Solitamente Microsoft richiede che venga fornito il dump della memoria del kernel. Di contro, il debugger analizza un mini-dump e, molto probabilmente, fornisce le informazioni necessarie alla risoluzione del problema. Se il mini-dump è tutto quello che si ha a disposizione, meglio eseguirne il debug piuttosto che attendere un successivo crash del sistema: aprire il file nel debugger (vedere oltre) così come si aprirebbe memory.dmp a scopo di esempio.
STOP code: il codice di errore che identifica l'errore che ha arrestato l'esecuzione del kernel del sistema. E' indicato dal primo insieme di valori esadecimali visualizzati nella schermata blu. Come minimo, gli amministratori dovrebbero annotare questo codice, gli altri quattro codici indicati in parentesi e qualsiasi altro driver identificato sullo schermo: spesso questo è tutto ciò di cui si ha bisogno.
Symbol files: tutte le applicazioni di sistema, i drivers e le DLLs sono realizzate in maniera tale che le loro informazioni di debugging risiedano in file separati conosciuti come symbol files. Pertanto, il sistema è più piccolo è più veloce, ma ne può essere comunque eseguito il debug se si hanno a disposizione i symbol files. Non è necessario disporre in anticipo dei symbol files per eseguire il debug: il debugger scaricherà automaticamente quelli necessari dal sito pubblico di Microsoft.

↑ Torna all'inizio

La schermata blu

Indipendentemente dal motivo alla base di un crash del sistema, la funzione che effettivamente esegue l'arresto è KeBugCheckEx, documentata nel Windows Driver Kit (WDK).  Questa funzione riceve un codice di stop (chiamato anche bugcheck code) e quattro parametri che devono essere interpretati in base al codice di stop. Dopo aver mascherato tutti gli interrupt su tutti i processori del sistema, KeBugCheckEx commuta il display in una modalità grafica VGA a bassa risoluzione (implementata da tutte le schede video supportate da Windows), imposta uno sfondo blu e visualizza il codice di stop, seguito da testo descrittivo che fornisce indicazioni sul da farsi all'utente.  Alla fine, KeBugCheckEx chiama tutte le funzioni di bugcheck callback registrate dai device drivers (registrate chiamando la funzione KeRegisterBugCheckCallback), consentendo ai drivers di arrestare i dispositivi da esssi controllati. Quindi inovca tutte le funzioni di reason callback (registrate chiamando la funzione KeRegisterBugCheckReasonCallback), che consento ai drivers di aggiungere dati al crash dump o di scrivere informazioni di crash dump ai devices sostitutivi. KeBugCheckEx visualizza la rappresentazione testuale del codice di stop vicino all'a parte superiore della schermata blu insieme con il codice di stop numerico e con i quattro parametri nella parte bassa dello schermo: la prima linea nella sezione Technical Information indica il codice di stop ed i quattro parametri addizionali passati alla funzione KeBugCheckEx; una linea di testo vicino alla parte alta dello schermo contiene l'equivalente testuale dell'identificatore numerico del codice di stop (a volte è perfino possibile che le strutture dati del sistema siano state corrotte in maniera tale da non consentire la visualizzazione delle schermata blu).

↑ Torna all'inizio

Identificare lo Stop Error

Esistono molti tipi diversi di errori di Stop: ognuno ha le sue possibili cause e richiede un preciso processo di risoluzione; quindi, il primo passo da compiere per risolvere un errore di Stop è identificarlo. Per iniziare è necessario disporre di alcune informazioni:

• numero dell'errore di Stop: questo numero identifica univocamente l'errore di Stop;
• parametri dell'errore di Stop: questi parametri forniscono informazioni aggiuntive relative all'errore di Stop. Il loro significato è specifico in base al numero dell'errore.
• informazione sul driver: quando è disponibile, l'informazione sul driver identifica la causa più probabile del problema. Comunque non tutti gli errori di Stop sono causati dai drivers.

Questa informazione è spesso visualizzata come parte del messaggio di Stop: se possibile, annotarla per utilizzarla come riferimento durante il processo di risoluzione del problema. Se il sistema operativo si riavvia prima che sia sato possibile prendere nota dell'informazione, sarà spesso possibile ricavarla dal log degli eventi "Sistema" presente nel Visualizzatore Eventi. Se non si è in grado di ricavare il numero dell'errore di Stop dal messaggio di Stop e dal log di sistema, è possibile ricavarlo dal file di dump della memoria. Per impostazione predefinita, Windows è cinfigurato per creare un dump della memoria ogni volta in cui si verifica un errore di Stop. Se il file di dump della memoria non è stato creato, si deve configurare il sistema affinchè lo faccia: quindi, qualora l'errore di Stop dovesse verificarsi nuovamente, si sarà in grado di estrarre le informazioni necessarie dal file di dump.

↑ Torna all'inizio

Comprendere il messaggio di Stop

Il messaggio di Stop riporta informazioni relative all'errore di Stop ed assiste l'amministratore di sistema (che sa come interpretare l'informazione) nell'isolare ed eventualmente risolvere il problema che ha causato l'errore di Stop. Il messaggio di Stop fornisce un gran numero di informazioni utili, compreso il numero dell'errore di Stop, o codice di bugcheck.  Il messaggio di Stop utilizza un modalità di visualizzazione a carattere a tutto schermo ed è composato da alcune sezioni principali, come mostrato in Figura 1, che visualizzano le seguenti informazioni:

• informazione sul bugcheck: questa sezione indica il nome descrittivo dell'errore di Stop. I nomi descrittivi sono correlati direttamente al numero di errore di Stop indicato nella sezione di informazioni tecniche;
• azione consigliata all'utente: questa sezione avverte l'utente che si è verificato un problema e che l'esecuzione di Windows è stata arrestata. Indica anche il nome simbolico dell'errore di Stop (in Figura 1, il nome simoblico è DRIVER_IRQL_NOT_LESS_OR_EQUAL). Cerca inoltre di descrivere il problema ed indica dei suggerimenti per il ripristino;
• informazioni tecniche: questa sezione indica il numero dell'errore di Stop, noto anche come codice di bugcheck, seguito da quattro codici specifici dell'errore (visualizzati come numeri esadecimali con il prefisso "0x" e racchiusi tra parentesi), che ne identificano i relativi parametri. In Figura 1, il numero dell'errore di Stop è 0x000000D1 (spesso scritto anche 0xD1);
• informazioni sui driver: questa sezione identifica il driver associato con l'errore di Stop;
• porta di debug e informazione sullo stato del dump: questa sezione indica i parametri delle porte Component Object Model (COM) che un debugger del kernel utilizza, se è stato abilitato. Se è stato abilitato il salvataggio dei files di dump della memoria, questa sezione indica anche se il file in questione è stato scritto con successo.

↑ Torna all'inizio

Recuperare il dump per un crash in modalità kernel

La maggior parte delle moderene installazioni desktop di Windows è configurata per recuperare automaticamente i dump piccoli della memoria. Le impostazioni di generazione del file di dump possono essere configurate nella scheda "Avanzate" della finestra delle proprietà di sistema, come è possibile vedere in Figura 4.

Figura 4: impostare le opzioni di generazione del file di dump.

La Tabella 1 riassume le differenti posizioni che Windows utilizza per memorizzare i file di dump della memoria (leggere anche l'articolo della Microsoft Knowledge Base KB254649 "Cenni preliminari sulle opzioni del file di immagine della memoria per Windows Vista, Windows Server 2008 R2, Windows Server 2008, Windows Server 2003, Windows XP e Windows 2000").

Tipo di dump	Posizione predefinita (variabile)	Posizione predefinita (tipica)	Requisiti per il file di paging
Dump ridotto della memoria	%systemroot%\Minidump\	c:\Windows\Minidump	>2 MB
Dump della memoria kernel	%systemroot%\Memory.dmp	c:\Windows\Memory.dmp	Abbastanza grande per la memoria kernel
Dump completo della memoria	%systemroot%\Memory.dmp	c:\Windows\Memory.dmp	Tutta la RAM fisica + 1 MB

Tabella 1: posizione e dimensione del file di dump della memoria.

Si può verificare la corretta generazione di un file di dump ogni volta in cui si verifica un errore di Stop forzando manualmente un crash di sistema: per ulteriori informazioni, leggere la pagina "Come provocare manualmente un errore di Stop di Windows e creare un file di dump (it-IT)".

↑ Torna all'inizio

Preparare l'ambiente

Il primo passo è procurarsi i Debugging Tools necessari per eseguire l'ananisi dei file di dump prodotti dopo un crash di sistema.
Le vecchie versioni dei Debugging Tools erano fornite come pacchetti di installazione standalone, scaricabili dal Microsoft Windows Hardware Dev Center, facendo attenzione a scaricare e ad installare la versione appropriata in base all'architettura del proprio sistema (32 bit o 64 bit); le versioni più recenti sono incluse nel Microsoft Windows SDK e nel Windows Driver Kit.
Se si decide di installare il Windows SDK, assicurarsi di contrassegnare la casella che includerà i Debugging Tools nel processo di installazione, come è possibile vedere in Figura 5.

Figura 5: installare il Windows SDK.

Dopo aver eseguito l'installazione, è necessario impostare il percorso dei simboli per assicurarsi che ve ne siano abbastanza a disposizione del debugger per capire cosa si è verificato e cosa era caricato in memoria. L'insieme completo dei simboli pubblicamente disponibili può essere scaricato su un disco locale, oppure si può specificare una posizione su Internet per scaricare i simboli quando richiesto. Il suggerimento è quello di scaricare i simboli da Internet: la versione corretta dei simboli sarà scaricata quando richiesto e non sarà resa obsoleta dall'installazione di hotfixes e service packs. L'articolo "Utilizzare Microsoft Symbol Server per ottenere i file di simboli di debug" (KB311503) della Microsoft Knowledge Base fornisce le istruzioni da seguire per utilizzare il Microsoft Symbol Server per ottenere i files contenenti i simboli di debug: semplicemente, si deve creare una cartella (per esempio, C:\Symbols) ed impostare la variabile di ambiente

_NT_SYMBOL_PATH = srv*c:\Symbols*http://msdl.microsoft.com/download/symbols

come è possibile vedere in Figura 6.

Figura 6: impostare la variabile _NT_SYMBOL_PATH.

↑ Torna all'inizio

Analizzare il file di dump del crash

Avviare WinDbg dal menu Start (la posizione esatta di WinDbg può variare in base alla propria versione di Windows) e selezionare File -> Open Crash Dump... (o premere CTRL+D): selezionare il file .DMP ed attendere che il debugger esegua le sue operazioni iniziali: vengono caricati i simboli del kernel ed il debugger visualizza alcune informazioni di base relative al sistema analizzato ed al bugcheck riportato, insieme all'indicazione del modulo probabile responsabile del crash di sistema.

Figura 7: avviare il processo di debugging.

Fatto ciò, è necessario ottenere informazioni dettagliate in merito all'ecezione o al bugcheck: nel pannello posto nella parte inferiore della finestra Command, digitare il comando "!analyze -v" e premere INVIO (l'opzione "-v" visualizza un output più dettagliato).

Figura 8-a: analizzare il file di dump (parte 1).

 

Figura 8-b: analizzare il file di dump (parte 2).

Come è possibile vedere, il sistema ha avuto un crash a causa di un bugcheck DRIVER_IRQL_NOT_LESS_OR_EQUAL, il cui codice di Stop è 0x000000D1. Il modulo malfunzionante sembra essere "e1k6232" (il nome del file di immagine è e1k6232.sys): digitiamo il comando "lm" con alcune opzioni aggiuntive ("v" attiva la visualizzazione di informazioni dettagliate, compreso il nome del file di simboli, il nome del file di immagine, informazioni sul checksum e sulla versione, data ed ora del file e l'indicazione relativa al fatto che il modulo contenga codice managed; "m" specifica un pattern che il nome del modulo deve soddisfare) come di seguito

Figura 9: visualizzare le informazioni sul modulo.

e si possono ottenere maggiori informazioni sul modulo in questione.
A questo punto, si procede ad eseguire una ricerca sul web (ad esempio, si può andare all'indirizzo http://systemexplorer.net/db/e1k6232.sys.html) e si scopre che "e1k6232.sys" è un driver che appartiene all'Intel Gigabit Adapter prodotto da Intel Corporation: in questo caso, potremmo risolvere il problema scaricando ed installando una versione aggiornata di questo driver (il file DMP usato nell'esempio proviene da un PC realmente affetto da questo problema e l'aggiornamento del driver lo ha effettivamente risolto). In base allo specifico errore può essere necessario eseguire ulteriori azioni.
Per alcuni errori può essere richiesta l'abilitazione del Driver Verifier per determinare la causa alla radice del problema: questo steumento verifica che i driver non eseguano chiamate di funzioni non consentite o non causino la corruzione del sistema ed è in grado di identificare delle condizioni come la corruzione della memoria, l'errata gestione dei pacchetti di richiesta di  I/O (IRPs), utilizzo non valido del buffer di accesso diretto alla memoria (DMA) e possibili deadlocks. L'estensione !verifier nel debugger del kernel può essere utilizzata per il monitoraggio e la produzione di report sulle statistiche relative al Driver Verifier nel contesto di una sessione di debugging.

↑ Torna all'inizio

Messaggi di Stop più comuni

Nelle sezioni seguenti, si illustreranno alcuni comuni casi di errrori di Stop e saranno fornite descrizioni ed informazioni utili per l'individuazione delle cause e la risoluzione di questi problemi.

Stop 0xD1 (IRQL_NOT_LESS_OR_EQUAL)

Il messaggio di Stop 0xD1 indica che il sistema ha eseguito un tentativo di accesso alla memoria paginabile usando un valore troppo elevato di IRQL per un processo in modalità kernel. Questo errore è solitamente causato da drivers che hanno utilizzato indirizzi di memoria non validi. Questo messaggio di Stop ha quattro parametri:

1. memoria referenziata
2. IRQL al momento dell'accesso
3. tipo di accesso
   • 0x00 = operazione di lettura
   • 0x01 = operazione di scrittura
4. indirizzo di memoria referenziato

I messaggi di Stop 0xD1 possono verificarsi in seguito all'installazione di drivers o servizi di sistema difettosi. Se viene indicato il nome di un driver, provare a disabilitarlo, rimuoverlo o ripristinarne una versione precedente per risolvere l'errore. Se la disabilitazione o la rimozionie dei driver risolve l'errore, informarsi presso il produttore del driver in merito alla disponibilità di un aggiornamento. L'utilizzo di software aggiornato è importante specialmente per i programmi di backup, applicazioni multimediali, scanners antivirus, riproduttori di DVD e strumenti di masterizzazzione di CD.

↑ Torna all'inizio

---

Risorse della Community

Pagine web su MSDN

• Blue Screen Data
• General Troubleshooting Tips
• Bug Check Code Reference - Questa pagina contiene una descrizione dei bug checks più comuni, comprensivi dei parametri visualizzati nella schermata blu. Descrive anche come è possibile diagnosticare il problema che ha causato il bug check ed i modi in cui si può trattare l'errore.
• Using Driver Verifier
• Interpreting a Bug Check Code (Windows Drivers)

Blogs

• Ntdebugging Blog
• Ask the Core Team Blog
• "The Case of the Crashed Phone Call" - Un altro esempio di analisi di un bugcheck realizzato da Mark Russinovich.
• Troubleshoot a Windows bluescreen, a.k.a bugcheck, a.k.a blue screen of death - Un esempio di analisi di bugcheck analysis tratto dal blog NDIS MSDN.
• What causes a bug check 0xD1 (IRQL_NOT_LESS_OR_EQUAL) - Indicazioni riguardo alla risoluzione di un caso molto comune di bugcheck dal blog NDIS MSDN.
• You got a B.S.O.D. (Blue Screen of Death, known as Bug Checks), now what?
• Understanding Bugchecks
• Understanding Crash Dump Files

Articoli della Microsoft Knowledge Base

• Checking Crashdump File for Corruption (KB119490)
• Blue Screen Preparation Before Contacting Microsoft (KB129845)
• How to Verify Windows Debug Symbols (KB148660)
• How to read the small memory dump files that Windows creates for debugging (KB315263)

Video

• Windows Crash Dump Analysis (TechEd 2009 Videos) - Daniel Pearson di David Solomon Expert Seminars esamina a Tech•Ed Europe alcuni crash dumps utilizzando i Microsoft Debugging Tools in casi reali di sistemi bloccati o in crash.

---

Vedere anche

Libri

• Windows Internals, 4th Edition (Chapter 14, "Crash Dump Analysis") di David A. Solomon e Mark E. Russinovich (Microsoft Press, Dicembre 2004)
• Windows Internals, 5th Edition (Chapter 14, "Crash Dump Analysis") di David A. Solomon, Mark E. Russinovich e Alex Ionescu (Microsoft Press, Giugno 2009)
• Windows 7 Resource Kit (Chapter 32, "Troubleshooting Stop Messages") di Mitch Tulloch, Tony Northrup, Jerry Honeycutt, Ed Wilson, ed il Windows 7 Team di Microsoft (Microsoft Press, Ottobre 2009)
• Inside Windows Debugging (Chapter 4, "Postmortem Debugging") by Tarik Soulami (Microsoft Press, Maggio 2012)

Articoli tecnici

• Analyzing Windows Crash Dump Files (The Code Project, 31 Ottobre 2008)

Siti web

• Dumpanalysis.org - Memory Dump, Software Trace, Debugging, Malware and Intelligence Analysis Portal.

---

Altre lingue

Questo articolo è disponibile anche nelle seguenti lingue:

English (en-US)

• Windows Bugcheck Analysis (en-US)