|
Titolo: [Win2000/XP/2003/Vista] Analisi dei Crash e dei Blocchi di Sistema Inserito da: rosmauro - 04 Gennaio 2008, 14:06:48 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: (http://www.visivaworld.it/Microsoft/Crash_Analysis/Images/Crash_Causes.jpg) 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. (http://www.visivaworld.it/Microsoft/Crash_Analysis/Images/Ultima_Configurazione_Funzionante.jpg) 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:
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: (http://www.visivaworld.it/Microsoft/Crash_Analysis/Images/PagingFile_Size.jpg) 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 (http://"http://oca.microsoft.com/") 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 (http://"http://www.microsoft.com/whdc/devtools/debugging/default.mspx"). Per realizzare questo tutorial oltre al già citato WinDbg (http://"http://www.microsoft.com/whdc/devtools/debugging/default.mspx"), mi sono servito di una utility della Sysinternals che si chiama NotMyFault (http://"http://www.visivaworld.it/Microsoft/Crash_Analysis/Bin/Notmyfault.zip"). 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: (http://www.visivaworld.it/Microsoft/Crash_Analysis/Images/High_IRQL_Fault.jpg) 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. (http://www.visivaworld.it/Microsoft/Crash_Analysis/Images/Buffer_Overflow.jpg) 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. (http://www.visivaworld.it/Microsoft/Crash_Analysis/Images/Code_Overwrite.jpg) 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: Codice: [LEFT]Percorso.: [B]HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\i8042prt\Parameters[/B] Per mettere in pratica la seconda opzone, bisogna avviare il sistema in modalità di debug. Questo lo si può fare in due modi diversi: [LIST=1]
Principali comandi del Debugger I principali comandi di WinDbg da ricordare sono i seguenti:
FONTE VisivaGroup.it Titolo: Re: [Win2000/XP/2003/Vista] Analisi dei Crash e dei Blocchi di Sistema Inserito da: Palermo Calcio - 13 Febbraio 2008, 05:17:55 rosmauro, ma per caso sei un ingegnere informatico? :o
:braaavo: Titolo: Re: [Win2000/XP/2003/Vista] Analisi dei Crash e dei Blocchi di Sistema Inserito da: rosmauro - 13 Febbraio 2008, 10:05:54 A fare copia e incolla sono tutti bravi..... (chiaramente ho inserito la fonte)
mi sembrava una cosa utile che potrebbe servire a tutti quei utenti poco esperti.... :fuma: :fuma: Titolo: Re: [Win2000/XP/2003/Vista] Analisi dei Crash e dei Blocchi di Sistema Inserito da: Palermo Calcio - 13 Febbraio 2008, 16:59:55 Hai fatto benissimo!!! :good:
Sai, non avevo notato la fonte e ti avevo scambiato per Bill Gates!!! :loool: :loool: :loool: :braaavo:
Powered by SMF 1.1.4 |
SMF © 2006-2007, Simple Machines LLC
Joomla Bridge by JoomlaHacks.com |