Qualsiasi utente dei Sistemi Operativi Microsoft, ha avuto a che fare, almeno una volta nella vita, con la famosa schermata blu di errore che ha comportato il conseguente blocco del sistema.
 
I BSOD o Blue Screen Of Death, come vengono affettuosamente chiamati nel mondo anglosassone, sono sempre stati estremamente ostici da analizzare e comprendere non solo per l’utente medio di PC, ma anche per gli addetti ai lavori come gli Amministratori di Sistema.
 
Lo scopo di questo tutorial, è quello di mostrare le tecniche e gli strumenti più adatti per l’analisi di un crash di sistema e per l’individuazione del componente che l’ha provocato.
 
Perché Windows va in Crash?
 
Cominciamo col dire che dall’analisi dei crash che gli utenti di Windows XP sottopongono alla Microsoft tramite il servizio Microsoft Online Crash Analysis (OCA), risultano le seguenti percentuali:
 

 
Come si può vedere, nel 70% dei casi il crash è causato da un driver di terze parti scritto male e solo nel 5% dei casi la causa è da imputare ad un componente di sistema. Questo fatto ci sarà di enorme aiuto nell’individuazione del componente che ha causato il crash in quanto i drivers di terze parti caricati all'avvio (e magari non firmati), sono in numero decisamente inferiore rispetto a quelli nativi del sistema operativo.
 
La Schermata Blu
 
Tecnicamente la schermata blu viene generata, a seguito di un errore grave, dalla funzione di sistema KeBugCheckEx. Questa funzione tra le altre cose, modifica la risoluzione del video alla risoluzione più bassa (VGA), imposta il colore dello sfondo sul Blu e infine visualizza il codice di stop seguito dalla rappresentazione testuale dello stesso e preceduto da una breve descrizione sui possibili motivi del crash e su quello che l’utente può fare. Purtroppo sia la descrizione dell’errore che il relativo codice di stop, sono quasi sempre di poco aiuto per l’utente. Esistono più di cento codici di stop ma per fortuna solo la minima parte di questi rappresenta la maggioranza dei crash di sistema.
 
Quando la schermata blu si presenta a seguito dell’installazione o aggiornamento di un driver, la cosa più ovvia da fare è quella di premere il tasto funzione F8 durante il riavvio del computer e selezionare l’opzione “Ultima configurazione sicuramente funzionante”. Selezionando questa opzione si forza il ripristino della chiave di registro HKLM\SYSTEM\CurrentControlSet\Services, contenente l’elenco dei drivers di periferica aggiornato all’ultimo avvio avvenuto con successo. Se invece la schermata blu si presenta a seguito dell’installazione di un software, allora si potrebbe avviare il sistema in modalità provvisoria è rimuovere il software incriminato. Se il problema non rientra nei due casi citati (cosa molto probabile), allora è indispensabile eseguire un’analisi più approfondita del crash dump.
 

 
Il Crash Dump File
 
Per impostazione predefinita tutti i sistemi Windows sono configurati per salvare le informazioni sul crash di sistema in un file su disco. Questo file viene chiamato “crash dump”. E’ possibile scegliere tra 3 differenti tipi di dump:

• Immagine della memoria ridotta: questa è l’opzione predefinita nei sistemi Windows 2000/XP. Questo dump viene anche chiamato minidump e contiene il codice di stop con i relativi parametri, la lista dei drivers caricati in memoria al momento del crash, la struttura dati comprendente il processo corrente e i relativi thread e lo stack per il thread che ha causato il crash. La dimensione di questo dump è di soli 64K per i sistemi a 32 bit e di 128K per i sistemi a 64 bit.
  
• Immagine della memoria kernel: questo dump contiene le pagine di memoria operanti in modalità kernel presenti nella memoria di sistema al momento del crash. Questo tipo di dump non contiene pagine che appartengono ai processi utente in quanto il crash di sistema può essere causato soltanto da codice operante in modalità kernel. In aggiunta, questo dump contiene tutte le strutture dati necessarie per l’analisi del crash come la lista dei processi in esecuzione, lo stack del thread corrente e la lista dei drivers caricati in memoria. Le dimensioni di questo dump non sono prevedibili in quanto dipendono direttamente dalla quantità di memoria operante in modalità kernel allocata dal sistema operativo e dal numero di drivers caricati in memoria.
  
• Immagine della memoria completa: il dump della memoria completa, contiene l’intero contenuto della memoria fisica così come si trovava al momento del crash. Questo tipo di dump richiede che il file di paging sia impostato ad una dimensione uguale o superiore alla quantità di memoria fisica presente nel sistema ed è l’impostazione predefinita per i sistemi operativi Server.

 
NOTA: Nonostante l’opzione predefinita per i sistemi 2000/XP sia quella della memoria ridotta, vedremo come la scelta migliore sia quella della memoria kernel. Non a caso l’impostazione predefinita per il nuovo Windows Vista, è proprio quella del dump della memoria kernel.
 
Il crash dump prima di essere salvato su disco viene scritto sul file di paging. Questo significa che per poter abilitare la creazione di un crash dump di memoria kernel o di memoria completa (ma non di memoria ridotta), è indispensabile utilizzare un file di paging di dimensioni adeguate al tipo di dump che si desidera ottenere. Per il dump della memoria completa è indispensabile impostare il file di paging ad una dimensione uguale alla quantità di memoria fisica più 1 MB per l’intestazione (dimensioni minime). Per il dump della memoria kernel, invece, bisogna attenersi indicativamente alla seguente tabella:
 

 
Online Crash Analysis (OCA)
 
I sistemi Windows XP/2003, includono una funzionalità chiamata Servizio di Segnalazione Errori. Questa funzionalità è abilitata per default e consente l’invio automatico di un crash dump al servizio Online Crash Analysis della Microsoft. Se l’utente, a seguito di un crash del sistema, sceglie di inviare le informazioni alla Microsoft, queste informazioni vengono analizzate da un sistema automatico (OCA) e il risultato, ove disponibile, viene immediatamente visualizzato sul browser dell’utente.
 
Se il sistema automatico di analisi fallisce o se si dispone di un sistema operativo che non supporta questa funzionalità (Windows 2000), allora è necessario analizzare il crash da soli. Fortunatamente la Microsoft ci mette a disposizione uno strumento gratuito che si chiama WinDbg e che utilizza lo stesso motore di analisi utilizzato dal sistema automatico OCA. WinDbg fa parte dei cosiddetti Debugging Tools for Windows.
 
Per realizzare questo tutorial oltre al già citato WinDbg, mi sono servito di una utility della Sysinternals che si chiama NotMyFault. NotMyFault è un piccolo eseguibile che una volta avviato, carica il driver myfault.sys nel sistema. Questo programma consente di generare svariati tipi di crash sul sistema nel quale viene eseguito. La terza e ultima utility che utilizzerò si chiama Driver Verifier Manager e, a differenza delle altre, è gia installata di default nei sistemi Win2000/XP/2003/Vista.
 
Analisi di base di un Crash Dump
 
Tornando all’utility NotMyFault, il crash di sistema più semplice da analizzare è senza dubbio quello che si può generare selezionando la prima voce della lista ovvero quello denominato High IRQL Fault.
 
La schermata blu di questo tipo di crash si presenta nel seguente modo:
 

 
Come si può vedere, viene indicato il codice di Stop D1 (STOP: 0x000000D1) anche chiamato BugCheck e la descrizione testuale dello stesso (DRIVER_IRQL_NOT_LESS_OR_EQUAL). In fondo alla pagina è indicato anche il driver che ha causato il crash. In questo caso non ci sarebbe neanche bisogno di analizzare il crash dump con WinDbg se non fosse che il sistema è impostato di default per il riavvio automatico e la schermata blu viene visualizzata per un tempo brevissimo prima del riavvio del sistema. La cosa da fare in questi casi, è quella di disattivare l’opzione “Riavvia automaticamente” presente nella finestra “Avvio e ripristino”. In questo modo abbiamo tutto il tempo di leggere le informazioni presenti sulla schermata blu di Windows. Una volta individuato il “colpevole”, è sufficiente avviare la console di ripristino, disabilitare il driver incriminato e riavviare il sistema normalmente.
 
Analisi avanzata di un Crash Dump
 
Il crash appena visto è abbastanza semplice da analizzare ma, sfortunatamente, molti altri crash non lo sono. Uno di questi è il cosiddetto Buffer Overflow Bug che si verifica quando un driver sovrascrive delle zone di memoria riservate ad altri drivers. Il BugCheck in questo caso è C5 (DRIVER_CORRUPTED_EXPOOL). Questo tipo di crash dump è virtualmente impossibile da analizzare in quanto il sistema va in crash solo quando i dati corrotti vengono referenziati e non quando si verifica la corruzione degli stessi. Analizzando il crash dump risultante, vedremo che il motore di analisi segnalerà come probabile causa del crash il file di sistema ntoskrnl.exe. Ovviamente questa informazione è del tutto fuorviante in quanto il vero colpevole và ricercato altrove.
 

 
Il sistema per individuare il vero colpevole per fortuna esiste e si chiama “Driver Verifier Manager”. Come ho già detto in precedenza, questa utiliy è presente di serie su tutti i sistemi 2000/XP/2003. Grazie ad essa è possibile monitorare un determinato numero di Drivers (o anche tutti) per fare in modo che il sistema si arresti nel momento stesso in cui si verifica la corruzione dei dati e non quando gli stessi vengono referenziati. Analizzando il crash dump risultante con WinDbg, questa volta ci verrà correttamente segnalato il vero colpevole.
 
Altro crash simile al precedente, è quello causato dal cosiddetto Code Overwrite Bug. Il BugCheck è 8E (KERNEL_MODE_EXCEPTION_NOT_HANDLED) e anche in questo caso, l’arresto del sistema si verifica in un momento successivo alla corruzione dei dati, rendendo il crash dump impossibile da analizzare. Il motore di analisi segnalerà come probabile causa del crash il solito file di sistema ntoskrnl.exe o altro file di sistema. Anche in questo caso è necessario far ricorso all’utility Driver Verifier Manager per trasformare un crash dump non analizzabile in un crash dump analizzabile.
 

 
Un altro crash frequente, è quello causato dallo Stack Overflow Bug che si verifica quando un driver sovrascrive una zona di memoria riservata che in questo caso è lo Stack. Questo tipo di bug è un altro di quelli molto difficili da scovare e, in questo caso, non può esserci d’aiuto neanche il Driver Verifier Manager. Per scovare il componente responsabile, sarà necessario procedere ad un’analisi manuale utilizzando comandi del debugger quali ad esempio il comando !thread e il comando !irp.
 
Ultimi ma non meno importanti sono quei bug che provocano malfunzionamenti particolari come il congelamento dell’intero sistema (Hang) o il blocco totale di una determinata applicazione o driver (Deadlock). Il primo problema da affrontare in questi casi, è quello di riuscire a creare un Crash Dump per la successiva analisi. Nei due casi citati, infatti, il sistema non va’ in crash e di conseguenza non viene generato il crash dump file. In entrambi i casi ci può essere d’aiuto il solito Driver Verifier Manager che monitorando i drivers sospetti, spesso è in grado di rilevare anche questo genere di problemi e di forzare il crash del sistema. Se neanche con questo strumento si riesce a forzare il crash del sistema, ci rimangono ancora due possibilità: la prima è quella di forzare il crash manualmente; la seconda è quella di avviare il sistema in modalità Debug e connettersi ad esso tramite cavo seriale null-modem.
 
Per mettere in pratica la prima opzione, è necessario aggiungere la seguente chiave di registro:
 
Una volta riavviato il computer, sarà possibile forzare il crash del sistema semplicemente premendo la combinazione di tasti Ctrl(destro) + Bloc Scorr + Bloc Scorr. In questo caso il codice di Stop sarà E2 (MANUALLY_INITIATED_CRASH). Da notare che il driver i8042prt è il driver di gestione delle tastiere PS/2 quindi per poter utilizzare questa funzionalità, è necessario disporre di una tastiera con attacco PS/2.
 
[LIST=1]

• Premere il tasto funzione F8 durante le primissime fasi di avvio e selezionare la voce “Modalità di Debug”
• Aggiungere l’apposita opzione direttamente nel file boot.ini.

Nel tutorial mostrerò entrambi gli approcci, anche se preferisco il secondo in quanto è possibile scegliere sia la porta COM da utilizzare che la velocità della stessa. Col primo metodo, invece, viene utilizzata automaticamente la porta COM2.
 
   

• !analyze –v : Mostra informazioni dettagliate sul codice di Stop che si sta analizzando
  
• !trhead : Mostra la lista dei thread attivi al momento del crash
  
• !irp [indirizzo] : Mostra le richieste di I/O per i thread in esecuzione al momento del crash
  
• !stacks : Mostra il contenuto dello Stack del kernel al momento del crash
  
• !process 0 0 : Mostra la lista dei processi attivi al momento del crash
  
• lm kv : Mostra la lista di tutti i drivers caricati in memoria
  
• !vm : Per verificare se il sistema ha esaurito la memoria virtuale, la memoria di paging o quella non di paging
  
• .dump [nomefile] : Salva una copia del Dump file sul computer locale
  
• .crash : provoca il crash del sistema che si sta debuggando.

Cinque consigli utili per la risoluzione dei problemi relativi ai crash di sistema[LIST=1]

• Disabilitare l’opzione “Riavvia automaticamente” presente nella finestra “Avvio e ripristino”
• Selezionare il dump della memoria Kernel al posto di quello della memoria ridotta
• Inserire la voce per l’avvio in Modalità di Debug nel file Boot.ini
• Installare la Console di Ripristino di emergenza (per i dettagli sulla procedura, leggere QUESTO HowTo)
  
• Abilitare la combinazione di tasti Ctrl(destro) + Bloc Scorr + Bloc Scorr per poter eseguire un crash manuale in caso di necessità.

FONTE VisivaGroup.it