Il server Windows ha appena visualizzato una Blue Screen of Death (BSOD) ed è il quarto crash che avete subito questa settimana. Cosa fare? Anche solo con una conoscenza di base dell'analisi di crash dump, e con pochi semplici comandi, potete determinare quale driver è coinvolto. Successivamente, attraverso una ricerca intelligente in Internet, dovreste poter individuare un hotfix o quantomeno una scappatoia che vi aiuti a eliminare la causa del crash.
Questa articolo vi illustrerà i tool necessari e gli step che dovrete affrontare per risolvere alcuni dei più complessi guasti ai server Windows.
Cosa succede quando si verifica un crash
Partiamo con il diagramma in basso, che vi fornisce una panoramica di ciò che succede quando si verifica un crash. Come si può vedere, quando il server si blocca riporta quanto contenuto nella memoria fisica (RAM) del file di paginazione sulla partizione di sistema.
Al riavvio, il pagrefile viene scritto nel file Memory.dmp, che risiede anche sulla partizione di sistema. Infine, dopo che il server ha terminato il reboot, è possibile utilizzare il debugger del kernel di Windows (WinDbg) con il symbol server di Microsoft per analizzare il crash.
Per facilitare la vostra analisi di crash dump, dovete considerare tre aree principali.
- In primo luogo, il server deve essere configurato in modo da generare un crash quando si verifica una condizione imprevista o un'eccezione.
- Quindi è necessario scarichiate il debugger Windows dal sito di Microsoft e impostiate la path del symbol server.
- Infine, utilizzate il debugger per analizzare il crash con pochi semplici comandi.
Esaminiamo più da vicino ciascuna di queste tre aree.
Configurare il dump
Per configurare il server affinché sia generato un crash, utilizzate la finestra che si apre attraverso la sequenza Pannello di controllo | System applet | Advanced tab |Startup | Recovery settings. Potete scegliere tra tre tipi di file dump della memoria: piccolo, a livello di kernel o completo. Di default, quando il server si blocca Windows produce un piccolo file "mini-dump".
Questo può talvolta contenere informazioni di debug, ma in genere è necessario avere un file dump a livello di kernel della memoria. In rari casi, potrebbe essere necessario configurare l'acquisizione completa del dump della memoria per catturare le informazioni di debbugging richieste. Se desiderate avere ulteriori informazioni sulla configurazione del file di immagine della memoria, le potete trovare nell'articolo 254649 della Microsoft Knowledge Base.
Installare il Windows debugger
Il passo successivo è l'installazione del tool per il debug del kernel di Windows, che può essere scaricato gratuitamente dal sito di Microsoft. Ci sono tre versioni di questo debugger (x86, x64 e IA64), in funzione dell'architettura del server di cui si prevede di analizzare il crash.
Una volta che WinDbg è installato, è necessario stabilire la symbol path per tradurre le locazioni di memoria in un riferimento significativo per le funzioni o le variabili utilizzate da Windows. La symbol path tipicamente utilizzata è SRV*c:\symbols*http://msdl.microsoft.com/download/. Nell'articolo 311503 della Microsoft Knowledge Base potete avere maggiori dettagli sulla creazione della symbol path per il vostro debugger.
Analizzare il crash
Ora che avete configurato il server per generare un memory dump e installato il debugger con la symbol path corretta, siete pronti ad analizzare un crash. Ci sono due modi per avviare il debugger: dal gruppo di programmi Debugging Tools for Windows o dal prompt DOS con il comando WinDbg. All'interno del debugger, cliccate sulla voce Open crash dump del menu a discesa File e fate puntare il debugger al vostro file dump.
Quando viene caricato tale file, noterete che lo schermo del debugger è diviso in due parti sovrapposte: il pannello di output, che occupa la maggior parte della finestra, e il prompt dei comandi in basso. Il primo comando che dovete utilizzare è il seguente:
! analyze -v
Questo comando esegue un'analisi preliminare del dump e vi propone un'indicazione del driver che con maggiore probabilità può essere stato la causa del crash. Le prime cose che vi mostra il comando sono il tipo di bug check (anche conosciuto come stop code) e gli argomenti.
Il tipo di bug check è importante e dovrebbe essere incluso nella vostra query quando eseguite una ricerca in Internet volta a individuare le possibili cause e gli eventuali fix.
Come possiamo vedere dal seguente esempio, WinDbg visualizza il tipo di bug check come un LM_SERVER_INTERNAL_ERROR (stop code 54). In questo caso, se cercate LM_SERVER_INTERNAL_ERROR nel sito di Microsoft, dovreste trovare che il problema è noto e che la documentazione relativa all'hotfix è disponibile nell'articolo 912947 della Microsoft KB. Anche il primo argomento corrisponde nell'articolo del KB.
3: kd> !analyze -v ***************************************************** * Bugcheck Analysis * *****************************************************
LM_SERVER_INTERNAL_ERROR (54)
Arguments:
Arg1: 00361595
Arg2: e8aab501
Arg3: 00000000
Arg4: 00000000
Il comando !analyze -v va alla ricerca del driver che ha causato il crash. Nel nostro esempio, il driver che ha causato il crash si chiama Srv.sys:
Probably caused by: srv.sys (srv!SrvVerifyDeviceStackSize+78 )
Diversi altri comandi utili forniscono maggiori informazioni circa il crash. Tra questi citiamo:
- !thread - elenca i thread attualmente in esecuzione
- - kv - visualizza lo stack trace indicando i driver e le funzioni che sono state chiamate
- - lm t n - visualizza l'elenco dei driver installati e i relativi dati
Infine, vi segnaliamo che l'help online del Windows debugger è eccellente. In particolare, potete cercare lo stop code per il crash e seguire le raccomandazioni della guida in linea che raccomanda risolvere il problema. Per trovare l'elenco degli stop code, cliccate sul menu Help e selezionate Contents | Debugging Tecnigue | Bug check (Blue screen) | Bug Check Code Reference. Poi scorrete l'elenco finché non individuate il vostro stop code.
*system software engineer
