Installazione degli strumenti di debug per Windows. Strumenti di debug di Windows: diagnosticare e correggere gli strumenti di debug BSOD per l'uso di Windows

il 22 giugno 2010

In precedenza Windbg era disponibile separatamente per il download. Ma per le ultime versioni, Microsoft lo mantiene come parte di Windows SDK. Si prega di trovare i link per il download di seguito.

Windows 10

L'ultima versione di Windbg per Windows 7 può essere scaricata dal link https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk

Windows 7

Scarica i programmi di installazione dai link sopra. Nota che questo non scarica l'intero SDK, è solo un programma di installazione. Una volta eseguito il file, puoi selezionare gli strumenti che desideri scaricare. Se sei interessato solo a Windbg, puoi escludere tutto il resto e selezionare solo "Strumenti di debug" in "Utilità comuni"

Il pacchetto sopra installa la versione di windbg 6.12. Se vuoi installare rapidamente windbg, puoi andare per la versione precedente (6.11) che può essere scaricata da
il link dato alla fine di questo post.

Una volta eseguita l'installazione, puoi trovare il programma nel menu Start -> Tutti i programmi -> Strumenti di debug per Windows -> Windbg

Al momento di un guasto critico, il sistema operativo Windows si interrompe e visualizza schermo blu morte (BSOD). Contenuto memoria ad accesso casuale e tutte le informazioni sull'errore che si è verificato vengono scritte nel file di paging. Alla prossima avvio di Windows viene creato un crash dump con informazioni di debug in base ai dati salvati. Viene generata una voce di errore critico nel registro eventi di sistema.

Attenzione! Un crash dump non viene generato se il sottosistema del disco fallisce o errore criticoè apparso nella fase iniziale dell'avvio di Windows.

Tipi di dump di arresto anomalo di Windows

Utilizzando l'esempio dell'attuale sistema operativo Windows 10 (Windows Server 2016), prenderemo in considerazione i principali tipi di dump della memoria che il sistema può creare:

Piccolo dump di memoria(256KB). Questo tipo di file contiene una quantità minima di informazioni. Contiene solo il messaggio di errore BSOD, le informazioni sui driver, i processi attivi al momento dell'arresto anomalo e quale processo o thread del kernel ha causato l'arresto anomalo.
Dump della memoria del kernel... Tipicamente di piccole dimensioni: un terzo della memoria fisica. Un dump della memoria del kernel è più dettagliato di un mini dump. Contiene informazioni su driver e programmi in modalità kernel e include memoria allocata al kernel di Windows e al livello di astrazione hardware (HAL) e memoria allocata a driver e altri programmi in modalità kernel.
Dump completo della memoria... Il volume più grande e richiede una memoria pari alla RAM del sistema più 1 MB, finestre richieste per creare questo file.
Dump automatico della memoria... Corrisponde al dump della memoria del kernel in termini di informazioni. Differisce solo in quanto spazio utilizza per generare il file dump. Questo tipo di file non esisteva in Windows 7. È stato aggiunto in Windows 8.
Dump memoria attiva... Questo tipo filtra gli elementi che non possono determinare la causa dell'errore di sistema. Questo è stato aggiunto in Windows 10 ed è particolarmente utile se stai utilizzando una macchina virtuale o se il tuo sistema è un host Hyper-V.

Come abilito il dump della memoria su Windows?

Usa Win + Pausa per aprire la finestra delle impostazioni di sistema, seleziona " Parametri di sistema aggiuntivi"(Impostazioni avanzate di sistema). Nella scheda " Inoltre"(Avanzate), sezione" "(Avvio e ripristino) clic" Opzioni"(Impostazioni). Nella finestra che si apre, configura le azioni in caso di guasto del sistema. Seleziona la casella di controllo " Scrivi eventi nel registro di sistema(Scrivi un evento nel registro di sistema), seleziona il tipo di dump da generare quando il sistema si arresta in modo anomalo. Se nella casella " Sovrascrivi file dump esistente"(Sovrascrivi qualsiasi file esistente) seleziona la casella, quindi il file verrà sovrascritto ad ogni errore. È meglio rimuovere questa casella di controllo, quindi avrai più informazioni per l'analisi. Disabilita anche Riavvia automaticamente.

Nella maggior parte dei casi, un piccolo dump della memoria sarà sufficiente per analizzare la causa del BSOD.

Ora, quando si verifica un BSOD, puoi analizzare il file di dump e trovare la causa degli arresti anomali. Il minidump viene salvato per impostazione predefinita nella cartella% systemroot% \ minidump. Per analizzare il file dump, consiglio di utilizzare il programma WinDBG(Debugger del kernel Microsoft).

Installazione di WinDBG su Windows

Utilità WinDBGè incluso in " Windows 10 SDK"(Windows 10 SDK). ...

Il file si chiama winsdksetup.exe, dimensione 1,3 MB.

Esegui l'installazione e scegli esattamente cosa vuoi fare: installa il pacchetto su questo computer o scaricalo per l'installazione su altri computer. Installa il pacchetto sul tuo computer locale.

È possibile installare l'intero pacchetto, ma per installare solo lo strumento di debug, selezionare Strumenti di debug per Windows.

Una volta installato, i collegamenti WinDBG si trovano nel menu di avvio.

Configurazione dell'associazione dei file .dmp con WinDBG

Per aprire i file dump con un semplice clic, abbinare l'estensione .dmp con l'utility WinDBG.

Aprire riga di comando come amministratore ed eseguire i comandi per il sistema a 64 bit: cd C:\Programmi (x86)\Windows Kits\10\Debuggers\x64
windbg.exe –IA
per un sistema a 32 bit:
C:\Programmi (x86)\Windows Kit\10\Debuggers\x86
windbg.exe –IA
Di conseguenza, i tipi di file: .DMP, .HDMP, .MDMP, .KDMP, .WEW - saranno associati a WinDBG.

Configurazione di un server di simboli di debug in WinDBG

I simboli di debug (simboli di debug o file di simboli) sono blocchi di dati generati durante la compilazione di un programma insieme a un file eseguibile. Tali blocchi di dati contengono informazioni sui nomi delle variabili, chiamate funzioni, librerie, ecc. Questi dati non sono necessari durante l'esecuzione del programma, ma sono utili durante il debug. I componenti Microsoft sono compilati con simboli distribuiti tramite Microsoft Symbol Server.

Configura WinDBG su uso di Microsoft Server di simboli:

Apri WinDBG;
Vai al menu File –> Percorso file simboli;
Aggiungere una riga contenente l'URL per il download dei simboli di debug dal sito Microsoft e la cartella per il salvataggio della cache: SRV * E: \ Sym_WinDBG * http: //msdl.microsoft.com/download/symbols Nell'esempio viene caricata la cache nella cartella E:\Sym_WinDBG, è possibile specificare qualsiasi.
Ricordati di salvare le modifiche al menu File–>Salva spazio di lavoro;

WinDBG cercherà i simboli nella cartella locale e, se non trova i simboli necessari in essa, scaricherà automaticamente i simboli dal sito specificato. Se vuoi aggiungere la tua cartella con i simboli, puoi farlo in questo modo:

SRV * E: \ Sym_WinDBG * http: //msdl.microsoft.com/download/symbols; c: \ Simboli

Se non disponi di una connessione Internet, scarica prima il pacchetto di simboli dalla risorsa Pacchetti di simboli di Windows.

Analisi del crash dump in WinDBG

Il debugger WinDBG apre il file dump e scarica i simboli di debug necessari da una cartella locale o da Internet. Durante questo processo, non è possibile utilizzare WinDBG. Nella parte inferiore della finestra (nella riga di comando del debugger), appare una scritta Debug non connesso.

I comandi vengono immessi nella riga di comando situata nella parte inferiore della finestra.

La cosa più importante a cui prestare attenzione è il codice di errore, che è sempre indicato in un valore esadecimale e assomiglia a 0xXXXXXXXX(indicato in una delle opzioni - STOP:, 02.07.2019 0008F, 0x8F). Nel nostro esempio, il codice di errore è 0x139.

Il debugger ti chiede di eseguire il comando!Analyze -v, passa il mouse sul collegamento e fai clic. A cosa serve questo comando?

Esegue un'analisi preliminare del dump della memoria e fornisce informazioni dettagliate per iniziare l'analisi.
Questo comando visualizzerà il codice STOP e il nome simbolico dell'errore.
Mostra lo stack di chiamate dei comandi che hanno provocato l'interruzione anomala.
Inoltre, qui vengono visualizzati errori nell'indirizzo IP, nei processi e nei registri.
Il team può fornire consigli già pronti per risolvere il problema.

I punti principali a cui prestare attenzione durante l'analisi dopo aver eseguito il comando!Analyze –v (l'elenco è incompleto).

1: kd>! Analizza -v

* *
* Analisi del controllo errori *
* *
*****************************************************************************
Il nome simbolico dell'errore STOP (BugCheck)
KERNEL_SECURITY_CHECK_FAILURE (139)
Descrizione dell'errore (un componente del kernel ha danneggiato una struttura dati critica. Questo danneggiamento potrebbe potenzialmente consentire a un utente malintenzionato di assumere il controllo di questa macchina):

Un componente del kernel ha danneggiato una struttura dati critica. Il danneggiamento potrebbe potenzialmente consentire a un utente malintenzionato di ottenere il controllo di questa macchina.
Argomenti di errore:

Argomenti:
Arg1: 0000000000000003, A LIST_ENTRY è stato danneggiato (ovvero doppia rimozione).
Arg2: ffffd0003a20d5d0, indirizzo del frame trap per l'eccezione che ha causato il bugcheck
Arg3: ffffd0003a20d528, Indirizzo del record dell'eccezione per l'eccezione che ha causato il bugcheck
Arg4: 0000000000000000, Riservato
Dettagli di debug:
------------------

Il contatore mostra quante volte il sistema si è bloccato con un errore simile:

CLIENTE_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: FAIL_FAST_CORRUPT_LIST_ENTRY

Codice di errore STOP in formato abbreviato:

BUGCHECK_STR: 0x139

Il processo durante l'esecuzione di cui si è verificato l'errore (non necessariamente la causa dell'errore, proprio al momento dell'errore in memoria questo processo era in esecuzione):

PROCESS_NAME: sqlservr.exe

Decrittografia del codice di errore: il sistema ha rilevato un overflow del buffer dello stack in questa applicazione, che potrebbe consentire a un utente malintenzionato di assumere il controllo di questa applicazione.

ERROR_CODE: (NTSTATUS) 0xc0000409 - Il sistema ha rilevato un sovraccarico di un buffer basato su stack in questa applicazione. Questo sovraccarico potrebbe potenzialmente consentire a un utente malintenzionato di ottenere il controllo di questa applicazione.
EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - Il sistema ha rilevato un sovraccarico di un buffer basato su stack in questa applicazione. Questo sovraccarico potrebbe potenzialmente consentire a un utente malintenzionato di ottenere il controllo di questa applicazione.

Ultima chiamata in pila:

LAST_CONTROL_TRANSFER: da fffff8040117d6a9 a fffff8040116b0a0

Stack di chiamate al momento dell'errore:

STACK_TEXT:
ffffd000`3a20d2a8 fffff804`0117d6a9: 00000000`00000139 00000000`00000003 ffffd000`3a20d5d0 ffffd000`3a20d528: nt! KeBugCheckEx
ffffd000`3a20d2b0 fffff804`0117da50: ffffe000`f3ab9080 ffffe000`fc37e001 ffffd000`3a20d5d0 fffff804`0116e2a2: nt! KiBugCheckDispatch + 0x69
ffffd000`3a20d3f0 fffff804`0117c150: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000: nt! KiFastFailDispatch + 0xd0
ffffd000`3a20d5d0 fffff804`01199482: ffffc000`701ba270 ffffc000`00000001 000000ea`73f68040 fffff804`000006f9: nt! KiRaiseSecurityCheckFailure + 0x3d0
ffffd000`3a20d760 fffff804`014a455d: 00000000`00000001 ffffd000`3a20d941 ffffe000`fcacb000 ffffd000`3a20d951: nt! ?? :: FNODOBFM :: `stringa" + 0x17252
ffffd000`3a20d8c0 fffff804`013a34ac: 00000000`00000004 00000000`00000000 ffffd000`3a20d9d8 ffffe001`0a34c600: nt! IopSynchronousServiceTail + 0x379
ffffd000`3a20d990 fffff804`0117d313: ffffffff`ffffffffe 00000000`00000000 00000000`00000000 000000eb`a0cf1380: nt! NtWriteFile + 0x694
ffffd000`3a20da90 00007ffb`475307da: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000: nt! KiSystemServiceCopyEnd + 0x13
000000ee`f25ed2b8 00000000`00000000: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000: 0x00007ffb`475307da

La sezione del codice in cui si è verificato l'errore:

FOLLOWUP_IP:
nt! KiFastFailDispatch + d0
fffff804`0117da50 c644242000 mov byte ptr, 0
FAULT_INSTR_CODE: 202444c6
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt! KiFastFailDispatch + d0
FOLLOWUP_NAME: proprietario della macchina

Il nome del modulo nella tabella degli oggetti del kernel. Se l'analizzatore rileva un driver problematico, il nome viene visualizzato nei campi MODULE_NAME e IMAGE_NAME:

MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe

1: kd> lmvm nt
Sfoglia l'elenco completo dei moduli
File immagine simbolo caricato: ntkrnlmp.exe
File immagine memoria mappata: C:\ProgramData\dbg\sym\ntoskrnl.exe\5A9A2147787000\ntoskrnl.exe
Percorso immagine: ntkrnlmp.exe
Nome immagine: ntkrnlmp.exe
InternalName: ntkrnlmp.exe
Nome file originale: ntkrnlmp.exe
Versione prodotto: 6.3.9600.18946
Versione file: 6.3.9600.18946 (winblue_ltsb_escrow.180302-1800)

Nell'esempio sopra, l'analisi ha puntato al file del kernel ntkrnlmp.exe. Quando l'analisi del dump della memoria punta a un driver di sistema (come win32k.sys) o un file del kernel (come ntkrnlmp.exe nel nostro esempio), è molto probabile questa vita non è la causa del problema. Molto spesso si scopre che il problema risiede nel driver del dispositivo, Impostazioni del BIOS o malfunzionamento dell'hardware.

Se hai visto che il BSOD è stato causato da un driver di terze parti, il suo nome verrà specificato nei valori MODULE_NAME e IMAGE_NAME.

Per esempio:

Percorso immagine: \ SystemRoot \ system32 \ drivers \ cmudaxp.sys
Nome immagine: cmudaxp.sys

Apri il file del driver e controlla la sua versione. Nella maggior parte dei casi, il problema con i driver viene risolto aggiornandoli.

Strumenti di debug per Windows- Strumenti di debug per il codice operativo Sistemi Windows... Sono un insieme di software gratuito di Microsoft progettato per eseguire il debug del codice in modalità utente e in modalità kernel: applicazioni, driver, servizi, moduli del kernel. Il toolkit include debugger in modalità console e GUI, utilità per lavorare con simboli, file, processi e utilità per il debug remoto. Il toolkit contiene utilità con cui è possibile trovare le cause dei guasti in vari componenti del sistema. Strumenti di debug per Windows da un certo momento non sono disponibili per il download sotto forma di kit di distribuzione autonomo e sono inclusi nel Windows SDK (Windows Software Development Kit). Insieme strumentale Strumenti di Windows L'SDK, a sua volta, è disponibile come parte del programma di abbonamento MSDN o può essere scaricato gratuitamente come distribuzione autonoma da msdn.microsoft.com. Secondo gli sviluppatori, l'ultimo e il più Versione corrente Strumenti di debug per Windows è contenuto in Windows SDK.

Gli strumenti di debug per Windows vengono aggiornati e resi disponibili al pubblico abbastanza spesso e questo processo non dipende dal rilascio dei sistemi operativi. Pertanto, controlla periodicamente la presenza di nuove versioni.

Vediamo ora per cosa, in particolare, gli Strumenti di Debug Microsoft Windows:

Eseguire il debug di applicazioni locali, servizi (servizi), driver e kernel;
Eseguire il debug di applicazioni, servizi (servizi), driver e kernel remoti sulla rete;
Eseguire il debug delle applicazioni in esecuzione in tempo reale;
Analizza i file di dump della memoria dell'applicazione, del kernel e del sistema nel suo insieme;
Lavorare con sistemi basati su architetture x86/x64/Itanium;
Debug di programmi in modalità utente e modalità kernel;

Sono disponibili le seguenti versioni degli strumenti di debug per Windows: x86 a 32 bit, Intel Itanium, x64 a 64 bit. Ne servono due: x86 o x64.

Esistono diversi modi per installare Strumenti di debug per Windows, in questo articolo prenderemo in considerazione solo i principali:

Installazione tramite il programma di installazione web.
Installazione degli strumenti di debug per Windows da ISO Immagine di Windows SDK.
Installazione degli strumenti di debug per Windows direttamente dai pacchetti dbg_amd64.msi /dbg_x86.msi.

Non è chiaro a che punto, perché dovrei installare il toolkit di debug sul mio computer? Spesso, dopotutto, ci si trova di fronte a una situazione in cui l'intervento in ambiente di lavoro altamente indesiderabile! Inoltre, l'installazione di un nuovo prodotto, ovvero apportare modifiche ai file di registro / di sistema, potrebbe essere completamente inaccettabile. Esempi sono i server mission critical. Perché gli sviluppatori non pensano a un'opzione con versioni portatili (portatili) di applicazioni che non richiedono installazione?
Il processo di installazione del pacchetto Strumenti di debug per Windows ha subito diverse modifiche da versione a versione. Passiamo ora direttamente al processo di installazione e esaminiamo i modi in cui è possibile installare il toolkit.

Installazione degli strumenti di debug per Windows utilizzando il programma di installazione Web

Vai alla pagina Archivio SDK di Windows e trova la sezione sotto Nome di Windows 10 e versioni precedenti, vedere "Windows 10 SDK (10586) e Microsoft Windows 10 Mobile Device Emulator (versione 10586.11)".

Clicchiamo sulla voce INSTALLA SDK... Dopo aver fatto clic, scaricare ed eseguire il file sdksetup.exe, che avvia l'installazione online di Windows SDK. Nella fase iniziale, il programma di installazione verificherà se il pacchetto .NET Framework è installato nel sistema. ultima versione(attualmente 4.5). Se il pacchetto è mancante, verrà proposta l'installazione e la stazione verrà riavviata al termine. Subito dopo il riavvio, in fase di autorizzazione dell'utente, il processo di installazione parte direttamente da Windows SDK.

Spesso, quando si scelgono tutti i componenti di un pacchetto senza eccezioni, possono verificarsi errori durante il processo di installazione. In questo caso, si consiglia di installare i componenti in modo selettivo, il set minimo richiesto.

Al termine dell'installazione di Strumenti di debug per Windows, il percorso dei file di debug per questo metodo di installazione sarà il seguente:

Versioni a 64 bit: C:\Programmi (x86)\Windows Kit\x.x\Debuggers\x64
Versioni a 32 bit: C:\Programmi (x86)\Windows Kit\x.x\Debuggers\x86

* dove x.x è una versione specifica del kit di sviluppo;
Abbiamo notato che le versioni 8 e successive, i percorsi di installazione sono notevolmente diversi da quelli classici per tutti versione precedente strumenti di debug?

Un enorme vantaggio questo metodo L'installazione degli strumenti di debug per Windows è l'installazione delle versioni degli strumenti di debug per tutte le architetture contemporaneamente.

Installazione degli strumenti di debug per Windows dall'immagine ISO di Windows SDK

Questo metodo prevede l'installazione degli strumenti di debug per Windows utilizzando un'immagine di installazione completa di Windows SDK (Software Developers Kit). Fino a un certo momento, era possibile scaricare l'immagine ISO per il sistema corrispondente nella pagina Archivio di Windows SDK. Tuttavia, al momento, è possibile ottenere un'immagine ISO dell'SDK eseguendo il programma di installazione web sdksetup.exe e selezionando la voce Scarica il kit di sviluppo software per Windows nella finestra di avvio del programma di installazione:

Come è stato scoperto, il precedente metodo di installazione utilizzando il programma di installazione Web è piuttosto capriccioso e spesso fallisce. Su sistemi puliti viene installato senza problemi, tuttavia, su sistemi sufficientemente caricati, sorgono numerosi problemi. Se hai solo un caso del genere, usa questo metodo.

Di conseguenza, nella pagina devi selezionare il kit di distribuzione richiesto, per me (e penso per molti) al momento è "Windows SDK per Windows 7 e .NET Framework 4" e appena sotto fai clic sul collegamento "Ottieni un Immagine ISO di un disco DVD" ...

Quando si lavora con il sito msdn.microsoft.com, ti consiglio di utilizzare un browser Internet Explorer perché ci sono stati casi di prodotti concorrenti non funzionanti!

Di conseguenza, è necessario scegliere solo quando necessario. Di solito il numero di bit di Strumenti di debug per Windows è lo stesso del sistema. I miei sistemi in esame sono per lo più a 64 bit, quindi nella maggior parte dei casi scarico l'immagine per il sistema a 64 bit GRMSDKX_EN_DVD.iso.
Quindi, dopo aver scaricato l'immagine, dobbiamo in qualche modo lavorare con l'immagine ISO esistente. Il modo tradizionale è, ovviamente, registrare un CD, ma questo è un metodo piuttosto lungo e talvolta costoso. Suggerisco di utilizzare utilità gratuite per la creazione di dispositivi di dischi virtuali nel sistema. Personalmente, preferisco usare il programma DEAMON Tools Lite per questo scopo. Qualcuno potrebbe avere altre preferenze, utilità più dirette o leggere, gusto e colore, come si suol dire.. Dopo l'installazione Strumenti del demonio Lite, faccio semplicemente doppio clic sul file immagine GRMSDKX_EN_DVD.iso e sul sistema appare un nuovo CD virtuale:

Quindi doppio click Attivo l'autorun e avvio l'installazione dell'SDK di Windows:

Quando arriva il turno di selezionare i componenti da installare dall'elenco, disabilitiamo assolutamente tutte le opzioni tranne quelle contrassegnate nello screenshot. Ciò contribuirà ad evitare errori inutili per noi ora.

Tutto è esattamente così, nello screenshot sono contrassegnate due opzioni: "Windows Performance Toolkit" e "Strumenti di debug per Windows". Scegli entrambi, perché Windows Performance Toolkit ti tornerà sicuramente utile per il tuo lavoro! Inoltre, dopo aver fatto clic sul pulsante "Avanti", l'installazione continua come al solito. E alla fine vedrai la scritta "Installazione completata".
Al termine dell'installazione, le directory di lavoro del set di Strumenti di debug per Windows saranno le seguenti:

Per la versione x86:
Per la versione x64:

Questo completa l'installazione di Strumenti di debug per Windows.

Installazione degli strumenti di debug per Windows tramite file .msi

In caso di problemi durante l'installazione di Strumenti di debug per Windows nei due modi precedenti, ne abbiamo ancora uno in più, il più affidabile e collaudato, che ha aiutato, per così dire, più di una volta. C'era una volta, prima dell'integrazione nell'SDK di Windows, gli strumenti di debug per Windows erano disponibili come programma di installazione .msi separato, che può ancora essere trovato ora, ma già nelle viscere del kit di distribuzione di Windows SDK. Dal momento che abbiamo già a portata di mano Immagine ISO di Windows SDK, quindi non possiamo montarlo nel sistema, ma semplicemente aprirlo utilizzando il noto archiviatore WinRAR, o qualsiasi altro prodotto che funzioni con il contenuto dei dischi ISO.

Dopo aver aperto l'immagine, dobbiamo andare nella directory "Setup" situata nella radice e quindi selezionare una delle directory:

Per installare la versione a 64 bit: \ Setup \ WinSDKDebuggingTools_amd64 e decomprimere il file dbg_amd64.msi da questa directory.
Per installare la versione a 32 bit: \ Setup \ WinSDKDebuggingTools e decomprimi il file dbg_x86.msi da questa directory.

Al termine dell'installazione, le directory di lavoro del set di Strumenti di debug per Windows saranno le seguenti:

Per la versione x86: C:\Programmi (x86)\Strumenti di debug per Windows (x86)
Per la versione x64: C:\Programmi\Strumenti di debug per Windows (x64)

A questo punto, l'installazione degli strumenti di debug per Windows è completa.

Informazioni aggiuntive

Non so a cosa sia collegato, forse per mia disattenzione, ma dopo aver installato gli strumenti di debug per Windows, il programma di installazione non registra il percorso della directory con il debugger nella variabile di sistema Path. Ciò impone alcune restrizioni all'avvio di varie attività di debug direttamente dalla console. Pertanto, in assenza di un percorso, scrivo io stesso nella finestra variabili ambientali percorso per gli strumenti di debug:

C:\Programmi (x86)\Windows Kit\10\Debuggers\x86
C:\Programmi (x86)\Windows Kit\10\Debuggers\x64

* Nel tuo caso, i percorsi potrebbero differire sia a causa dell'uso di un sistema operativo di un bit diverso, sia a causa dell'uso dell'SDK di una versione diversa.

Gli strumenti di debug per le utility del pacchetto Windows possono funzionare come applicazioni portatili, è sufficiente copiare la directory dal sistema di lavoro Microsoft Windows Performance Toolkit e usalo come versione portatile su un server di produzione. Ma non dimenticare di tenere conto della capacità del sistema !! Anche se hai installato completamente il pacchetto su un sistema critico, puoi iniziare a lavorare subito dopo l'installazione, non è necessario riavviare.

Strumenti di debug per la composizione di Windows

Ed ora, finalmente, vi presentiamo la composizione degli Strumenti di Debug per Windows:

File	Appuntamento
adplus.doc	Documentazione per l'utilità ADPlus.
adplus.exe	Un'applicazione console che automatizza il debugger cdb per creare dump, file di registro per uno o più processi.
agestore.exe	Un'utilità per rimuovere i file obsoleti dal repository utilizzato dal server di simboli o dal server di origine.
breakin.exe	Un'utilità che consente di inviare una combinazione di interruzioni definita dall'utente ai processi, in modo simile alla pressione di CTRL + C.
cdb.exe	Un debugger della console in modalità utente.
convertstore.exe	Utility per convertire i simboli da 2-tier a 3-tier.
dbengprx.exe	Reaper (server proxy) per il debug remoto.
dbgrpc.exe	Utility per visualizzare informazioni sullo stato di una chiamata RPC.
dbgsrv.exe	Processo del server utilizzato per il debug remoto.
dbh.exe	Un'utilità per visualizzare informazioni sul contenuto di un file di simboli.
dumpchk.exe	Utilità di controllo del dump. Un'utilità per controllare rapidamente un file di dump.
dumpexam.exe	Un'utilità per l'analisi di un dump della memoria. Il risultato viene visualizzato in% SystemRoot% \ MEMORY.TXT.
gflags.exe	L'editor dei flag globali del sistema. L'utilità gestisce le chiavi di registro e altre impostazioni.
i386kd.exe	Involucro per kd. Quando è stato chiamato kd per i sistemi basati su Windows NT/2000 per macchine x86? Probabilmente lasciato per motivi di compatibilità.
ia64kd.exe	Involucro per kd. Quando è stato chiamato kd per i sistemi basati su Windows NT / 2000 per macchine ia64? Probabilmente lasciato per motivi di compatibilità.
kd.exe	Debugger per console in modalità kernel.
kdbgctrl.exe	Strumento di gestione del debug del kernel. Utility per la gestione e la configurazione della connessione di debug del kernel.
kdsrv.exe	Server di connessione per KD. L'utilità è una piccola applicazione che si avvia e attende connessioni remote... kd viene eseguito sul client e si connette a quel server per il debug remoto. Sia il server che il client devono appartenere allo stesso assembly degli strumenti di debug.
kill.exe	Utilità per terminare i processi.
list.exe	Un'utilità per visualizzare il contenuto di un file sullo schermo. Nel pacchetto, questa utility in miniatura si è rivelata con uno scopo: visualizzare testo di grandi dimensioni o file di registro. Occupa poco spazio di memoria poiché carica il testo in blocchi.
logger.exe	Un debugger in miniatura che può funzionare solo con un processo. L'utilità inietta logexts.dll nello spazio del processo, che registra tutte le chiamate di funzione e altre azioni del programma in esame.
logviewer.exe	Un'utilità per visualizzare i registri scritti dal debugger logger.exe.
ntsd.exe	Debugger simbolico di Microsoft NT (NTSD). Debugger, identico a cdb, tranne per il fatto che crea una casella di testo all'avvio. Come cdb, ntsd è in grado di eseguire il debug sia delle applicazioni console che delle applicazioni grafiche.
pdbcopy.exe	Un'utilità per rimuovere i simboli privati da un file di simboli, controllo sui simboli pubblici inclusi nel file di simboli.
remote.exe	Utility per il debug e il controllo remoto di qualsiasi debugger di console KD, CDB e NTSD. Consente di eseguire tutti questi debugger della console in remoto.
rtlist.exe	Visualizzatore attività remota. L'utilità viene utilizzata per elencare i processi in esecuzione tramite il processo del server DbgSrv.
symchk.exe	Utility per scaricare simboli da Microsoft Symbol Server e creare una cache dei simboli locale.
symstore.exe	Utility per la creazione di una rete o archiviazione locale di simboli (2 livelli / 3 livelli). Un archivio di simboli è una directory specializzata su disco che è costruita secondo una certa struttura e contiene simboli. Nella directory radice dei simboli viene creata una struttura di sottocartelle con nomi identici ai nomi dei componenti. A sua volta, ciascuna di queste sottocartelle contiene sottocartelle nidificate con nomi speciali ottenuti dall'hashing dei file binari. L'utilità symstore esegue la scansione delle cartelle dei componenti e aggiunge nuovi componenti all'archivio dei simboli, da dove possono essere recuperati da qualsiasi client. Si dice che il symstore venga utilizzato per ottenere simboli da uno storage di livello 0 e inserirli in uno storage a 2 livelli/3 livelli.
tlist.exe	Visualizzatore attività. Un'utilità per elencare tutti i processi in esecuzione.
umdh.exe	Utilità heap dump in modalità utente. Utility per analizzare gli heap (heap) del processo selezionato. Consente di visualizzare varie opzioni per l'heap.
usbview.exe	Visualizzatore USB. Utility per la visualizzazione dei dispositivi USB collegati al computer.
vmdemux.exe	Demultiplatore macchina virtuale... Crea più pipe denominate per una singola connessione COM. I canali vengono utilizzati per eseguire il debug di vari componenti della macchina virtuale
windbg.exe	Debugger GUI in modalità utente e modalità kernel.

Presentazione di WinDBG - Parte 1

Alessandro Antipov

WinDBG è un ottimo debugger. Potrebbe non avere un'interfaccia molto intuitiva e non ha uno sfondo nero per impostazione predefinita, ma al momento è uno dei debugger più potenti e stabili di Windows. In questo articolo, ti guiderò attraverso le basi di WinDBG in modo che tu possa iniziare con esso.

Questo è il primo articolo di una serie su WinDBG. Elenco di tutti gli articoli inclusi in questo ciclo:

Parte 1 - installazione, interfaccia, simboli, debug remoto/locale, sistema di aiuto, moduli, registri.
Parte 2 - Punti di interruzione.
Parte 3 - ispezione della memoria, debug del programma passo passo, suggerimenti e trucchi.

In questo articolo tratteremo l'installazione e la connessione a un processo, e in seguito tratteremo i punti di interruzione, il debug passo dopo passo e l'ispezione della memoria.

Installazione di WinDBG

Rispetto a Windows 7, il processo di installazione di WinDBG in Windows 8 ha subito lievi modifiche. In questa sezione, ti guideremo attraverso l'installazione del debugger per entrambi i sistemi operativi.

Installazione di WinDBG su Windows 8

Su Windows 8, WinDBG è incluso nel Windows Driver Kit (WDK). È possibile installare Visual Studio e WDK oppure installare separatamente il pacchetto Strumenti di debug per Windows 8.1, che include WinDBG.

Il programma di installazione ti chiederà se desideri installare WinDBG localmente o scaricare l'intero pacchetto per sviluppatori per un altro computer. Quest'ultimo è essenzialmente l'equivalente di un programma di installazione offline, il che è ottimo se si desidera installare il pacchetto su altri sistemi in futuro.

Figura 1: Selezione di un tipo di installazione

Nella finestra successiva, devi deselezionare tutti gli elementi tranne "Strumenti di debug per Windows" e fare clic sul pulsante "Download".

Non appena il programma di installazione termina il suo lavoro, vai nella directory in cui è stato scaricato il pacchetto (di default è c: \ Users \ Username \ Downloads \ Windows Kits \ 8.1 \ StandaloneSDK) e segui la procedura di installazione.

Installazione di WinDBG su Windows 7 e versioni precedenti

Per Windows 7 e versioni precedenti, WinDBG è incluso nel pacchetto Strumenti di debug per Windows, incluso in Windows SDK e .Net Framework. Dovrai scaricare il programma di installazione, quindi selezionare "Strumenti di debug per Windows" durante il processo di installazione.

Durante l'installazione, seleziono l'opzione Strumenti di debug in Pacchetti ridistribuibili per creare un programma di installazione autonomo per facilitare le installazioni successive.

Figura 2: Selezione delle opzioni di installazione per creare un programma di installazione autonomo

Al termine dell'installazione, dovresti avere i programmi di installazione di WinDBG per varie piattaforme (nella directory c: \ Program Files \ Microsoft SDKs \ Windows \ v7.1 \ Redist \ Debugging Tools for Windows \).

Figura 3: Cartella con i programmi di installazione di WinDBG per diverse piattaforme

Interfaccia WinDBG

Figura 4: Aspetto di WinDBG

Non appena vedi per la prima volta aspetto esteriore WinDGB, scoprirai che il debugger è spaventosamente semplice. La maggior parte delle funzionalità di WinDBG viene appresa durante il debug del processo. Invece di perdere tempo a descrivere l'interfaccia, nelle sezioni seguenti tratteremo solo i punti più importanti.

La cosa più basilare che devi sapere sull'interfaccia del debugger è la finestra di comando, che ha due aree. La prima area: una finestra in cui viene visualizzato il risultato dell'esecuzione del comando. Seconda area: un piccolo campo di testo per l'immissione dei comandi.

Figura 5: finestra di comando WinDBG

Simboli

Nella maggior parte dei casi, WinDBG non richiede alcuna impostazione speciale e funziona correttamente. Ma una cosa importante da modificare sono i simboli. I simboli sono file che vengono generati con un file eseguibile durante la compilazione di un programma e contengono informazioni di debug (funzioni e nomi di variabili). Le informazioni di debug ti consentono di esplorare la funzionalità della tua applicazione durante il debug o il disassemblaggio. Molti componenti Microsoft sono compilati con simboli distribuiti tramite Microsoft Symbol Server. Con il resto dei file eseguibili, tutto non è così roseo: molto raramente i file con informazioni di debug vengono forniti con l'applicazione. Nella maggior parte dei casi, le aziende limitano l'accesso a tali informazioni.

Per configurare WinDBG per l'utilizzo di Microsoft Symbol Server, vai su File: Symbol File Path e imposta SRV * C: \ Symbols * http: //msdl.microsoft.com/download/symbols. Certo, è un po' strano che gli asterischi siano usati come separatori. Dopo aver configurato Microsoft Symbol Server, i simboli vengono scaricati nella cartella C:\Simboli.

Figura 6: Configurazione di Microsoft Symbol Server

WinDBG caricherà automaticamente i simboli per i binari quando necessario. Puoi anche aggiungere la tua cartella di simboli, in questo modo:

SRV * C: \ Simboli * http: //msdl.microsoft.com/download/symbols; c: \ SomeOtherSymbolFolder

Aggiunta di simboli durante il debug

Se hai bisogno di importare simboli durante il debug, puoi farlo con .sympath (apparirà una finestra di comando quando ti colleghi a un processo). Ad esempio, per aggiungere la cartella c: \ SomeOtherSymbolFolder, inserisci il seguente comando:

0: 025> .sympath + c: \ SomeOtherSymbolFolder
Il percorso di ricerca dei simboli è: SRV * C: \ Symbols * http: //msdl.microsoft.com/download/symbols; c: \ SomeOtherSymbolFolder
Il percorso di ricerca dei simboli espansi è: srv * c: \ symbol * http: //msdl.microsoft.com/download/symbols; c: \ someothersymbolfolder

Non sarà superfluo ricaricare i simboli dopo aver aggiunto o modificato i percorsi:

0: 025> .ricarica
Ricaricare i moduli attuali
................................................................
...............................................

Controllo dei simboli caricati

Per vedere per quali moduli sono caricati i simboli, puoi usare il comando x *!. Sebbene WinDBG carichi solo i simboli necessari, x *! mostrerà i simboli che possono essere caricati. Puoi forzare il caricamento dei simboli con il comando ld * (questo può richiedere del tempo e puoi fermare questo processo andando su Debug: Break).

Ora possiamo vedere i simboli per ogni modulo.

Figura 8: Elenco dei simboli

Debug di un processo locale

Quando si esegue il debug di un processo locale, sono disponibili due percorsi:

Collegati a un processo già in esecuzione.
Avvia il processo tramite WinDBG.

Ogni metodo ha i suoi vantaggi e svantaggi. Se, ad esempio, si esegue il programma tramite WinDBG, sono disponibili alcune opzioni di debug speciali (ad esempio, il debug dell'heap) che possono causare l'arresto anomalo dell'applicazione. D'altra parte, ci sono anche programmi che si bloccano quando si collega loro un debugger. Alcune applicazioni (soprattutto malware) verificano la presenza di un debugger nel sistema durante l'avvio e, di conseguenza, in questo caso ha senso aggrapparsi a un processo già in esecuzione. A volte c'è un debug di un servizio in esecuzione nel sistema operativo Windows, che imposta alcuni parametri durante l'avvio, quindi per semplificare il processo di debug, è anche meglio collegarsi al processo in esecuzione, piuttosto che avviare il servizio tramite il debugger. Alcune persone sostengono che l'avvio di un processo tramite il debugger abbia un grave impatto sulle prestazioni. In breve, prova entrambi e scegli quello che funziona meglio per te. Se per qualche motivo preferisci un metodo particolare, condividi i tuoi pensieri nei commenti!

Inizio del processo

Se stai eseguendo il debug di un'applicazione autonoma in esecuzione localmente e non in rete, potresti volerla eseguire tramite WinDBG. Tuttavia, questo non significa che non puoi agganciarti a un processo già in esecuzione. Scegli il metodo più conveniente per te.

Non è difficile avviare il processo. Vai su "File: Apri eseguibile" e seleziona il file eseguibile di cui desideri eseguire il debug. Puoi anche fornire argomenti o impostare la directory di avvio:

Figura 9: Selezione del file eseguibile per il debug

Connessione al processo

Anche la connessione a un processo già in esecuzione non è difficile. Tieni presente, tuttavia, che in alcuni casi potrebbe essere necessario un po' di tempo per trovare il processo esatto di cui desideri eseguire il debug. Ad esempio, alcuni browser creano un processo padre e poi molti altri processi per ogni scheda. Pertanto, a seconda del crash dump di cui si sta eseguendo il debug, potrebbe essere necessario collegarsi non al processo padre, ma al processo associato alla scheda.

Per collegarsi a un processo già in esecuzione, andare su "File: Allega a un processo" e quindi selezionare il PID o il nome del processo. Ricorda che devi avere i diritti appropriati per poter riprendere il processo.

Figura 10: Selezione del processo a cui agganciarsi

Se, dopo la connessione, l'applicazione ha sospeso il suo lavoro, puoi utilizzare la modalità "Non invadere" selezionando la casella di controllo corrispondente.

Debug di un processo remoto

A volte potrebbe essere necessario eseguire il debug di un processo su un sistema remoto. Sarebbe molto più conveniente farlo con un debugger locale invece di utilizzare una macchina virtuale o RDP. O forse stai eseguendo il debug del processo LoginUI.exe, che è disponibile solo quando il sistema è bloccato. In situazioni come questa, puoi utilizzare la versione locale di WinDBG e connetterti ai processi in remoto. Esistono due modi più comuni per eseguire queste attività.

Sessioni di debug esistenti

Se hai già avviato il debug del tuo programma localmente (collegandoti o avviando un processo tramite WinDBG), puoi inserire un comando specifico e WinDBG avvierà un "ascoltatore" a cui il debugger remoto può connettersi. Per fare ciò, usa il comando .server:

TCP server: porta = 5005

Dopo aver eseguito il comando sopra, potresti vedere un avviso come questo:

Figura 11: Un messaggio di avviso che può apparire dopo aver eseguito il comando per creare un "ascoltatore"

Quindi WinDBG segnalerà che il server è in esecuzione:

0: 005> .server tcp: porta = 5005
0: -tcp remoto: Porta = 5005, Server = UTENTE-PC

Ora puoi connetterti da un host remoto a una sessione di debug esistente andando su "File: Connetti a una sessione remota" e digitando qualcosa del genere nel campo di testo: tcp: Port = 5005, Server = 192.168.127.138

Figura 12: Connessione remota a una sessione di debug

Dopo la connessione, riceverai una conferma sul client remoto:

Server avviato. Il cliente può connettersi con una qualsiasi di queste righe di comando
0: -tcp remoto: Porta = 5005, Server = UTENTE-PC
MACHINENAME \ Utente (tcp 192.168.127.138:13334) connesso a Mon Dec 16 09:03:03 2013

e un messaggio a versione locale debugger:

MACHINENAME \ Utente (tcp 192.168.127.138:13334) connesso a Mon Dec 16 09:03:03 2013

Creazione di un server remoto

Puoi anche creare un server separato con WinDBG, connetterti ad esso in remoto e selezionare un processo di cui eseguire il debug. Questa operazione può essere eseguita utilizzando il file dbgsrv.exe in cui si prevede di eseguire il debug dei processi. Per avviare un server di questo tipo, esegui il seguente comando:

dbgsrv.exe -t tcp: porta = 5005

Figura 13: Avvio del server remoto

Di nuovo, potresti ricevere un avviso di sicurezza che dovresti accettare:

Figura 14: messaggio di sicurezza che può apparire durante l'avvio del server di debug

Puoi connetterti al server di debug andando sul file "File: Connect to Remote Stub" e inserendo la seguente riga nel campo di testo: tcp: Porta = 5005, Server = 192.168.127.138

Figura 15: Connessione a un server di debug

Dopo la connessione, non riceverai alcun segnale che sei connesso, ma se vai su "File: Allega a un processo", vedrai un elenco dei processi del server di debug (dove è in esecuzione dbgsrv.exe). Ora puoi agganciarti al processo come se lo stessi facendo localmente.

Sistema di aiuto

Il sistema di aiuto in WinDBG è fantastico. Oltre a imparare qualcosa di nuovo, dovresti essere in grado di ottenere informazioni di base su un comando. Utilizzare il comando .hh per accedere alla Guida di WinDBG:

Puoi anche ottenere informazioni di aiuto per un comando specifico. Ad esempio, per ottenere assistenza con il comando .reload, utilizzare il comando seguente:

windbg> .hh .ricarica

Oppure vai alla sezione Aiuto: Contenuti.

Moduli

Mentre il programma è in esecuzione, vengono importati vari moduli che forniscono la funzionalità dell'applicazione. Pertanto, se sai quali moduli vengono importati dall'applicazione, puoi capire meglio come funziona. In molti casi, effettuerai il debug di un modulo specifico caricato da un programma, non dell'eseguibile stesso.

Dopo essersi connesso al processo, WinDBG visualizzerà automaticamente i moduli caricati. Ad esempio, i moduli seguenti vengono visualizzati dopo la connessione a calc.exe:

*** aspetta con allegato in sospeso
Il percorso di ricerca dei simboli è: SRV * C: \ Symbols * http: //msdl.microsoft.com/download/symbols
Il percorso di ricerca eseguibile è:
ModLoad: 00a70000 00b30000 C:\Windows\system32\calc.exe
ModLoad: 77630000 7776c000 C: \ Windows \ SYSTEM32 \ ntdll.dll
ModLoad: 77550000 77624000 C: \ Windows \ system32 \ kernel32.dll
ModLoad: 75920000 7596a000 C: \ Windows \ system32 \ KERNELBASE.dll
ModLoad: 7641000 77059000 C: \ Windows \ system32 \ SHELL32.dll
ModLoad: 77240000 772ec000 C:\Windows\system32\msvcrt.dll
ModLoad: 76300000 76357000 C: \ Windows \ system32 \ SHLWAPI.dll
ModLoad: 75cd0000 75d1e000 C: \ Windows \ system32 \ GDI32.dll
ModLoad: 75fa0000 76069000 C:\Windows\system32\USER32.dll
ModLoad: 777b0000 777ba000 C: \ Windows \ system32 \ LPK.dll
ModLoad: 774b0000 7754d000 C: \ Windows \ system32 \ USP10.dll
ModLoad: 73110000 732a0000 C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_
6595b64144ccf1df_1.1.7600.16385_none_72fc7cbf861225ca \ gdiplus.dll
ModLoad: 75a80000 75bdc000 C:\Windows\system32\ole32.dll
ModLoad: 76360000 76401000 C:\Windows\system32\RPCRT4.dll
ModLoad: 777c0000 77860000 C:\Windows\system32\ADVAPI32.dll
ModLoad: 75be0000 75bf9000 C: \ Windows \ SYSTEM32 \ sechost.dll
ModLoad: 76270000 762ff000 C:\Windows\system32\OLEAUT32.dll
ModLoad: 74590000 745d0000 C:\Windows\system32\UxTheme.dll
ModLoad: 74710000 748ae000 C: \ Windows \ WinSxS \ x86_microsoft.windows.common-
ModLoad: 703d0000 70402000 C:\Windows\system32\WINMM.dll
ModLoad: 74c80000 74c89000 C: \ Windows \ system32 \ VERSION.dll
ModLoad: 77770000 7778f000 C: \ Windows \ system32 \ IMM32.DLL
ModLoad: 75c00000 75ccc000 C: \ Windows \ system32 \ MSCTF.dll
ModLoad: 74130000 7422b000 C:\Windows\system32\WindowsCodecs.dll
ModLoad: 74260000 74273000 C:\Windows\system32\dwmapi.dll
ModLoad: 756d0000 756dc000 C: \ Windows \ system32 \ CRYPTBASE.dll
ModLoad: 75e60000 75ee3000 C: \ Windows \ system32 \ CLBCatQ.DLL
ModLoad: 6ef10000 6ef4c000 C: \ Windows \ system32 \ oleacc.dll

Successivamente nel processo di debug, è possibile visualizzare nuovamente questo elenco con il comando lmf:

0: 005> lmf
inizio fine nome modulo
00a70000 00b30000 calc C:\Windows\system32\calc.exe
6ef10000 6ef4c000 oleacc C:\Windows\system32\oleacc.dll
703d0000 70402000 WINMM C:\Windows\system32\WINMM.dll
73110000 732a0000 gdiplus C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_
1.1.7600.16385_none_72fc7cbf861225ca \ gdiplus.dll
74130000 7422b000 WindowsCodecs C:\Windows\system32\WindowsCodecs.dll
74260000 74273000 dwmapi C:\Windows\system32\dwmapi.dll
74590000 745d0000 UxTheme C: \ Windows \ system32 \ UxTheme.dll
74710000 748ae000 COMCTL32 C:\Windows\WinSxS\x86_microsoft.windows.common-
controlli_6595b64144ccf1df_6.0.760.16385_none_421189da2b7fabfc \ COMCTL32.dll
74c80000 74c89000 VERSIONE C:\Windows\system32\VERSIONE.dll
756d0000 756dc000 CRYPTBASE C: \ Windows \ system32 \ CRYPTBASE.dll
75920000 7596a000 KERNELBASE C: \ Windows \ system32 \ KERNELBASE.dll
75a80000 75bdc000 ole32 C:\Windows\system32\ole32.dll
75be0000 75bf9000 sechost C: \ Windows \ SYSTEM32 \ sechost.dll
75c00000 75ccc000 MSCTF C: \ Windows \ system32 \ MSCTF.dll
75cd0000 75d1e000 GDI32 C: \ Windows \ system32 \ GDI32.dll
75e60000 75ee3000 CLBCatQ C: \ Windows \ system32 \ CLBCatQ.DLL
75fa0000 76069000 USER32 C: \ Windows \ system32 \ USER32.dll
76270000 762ff000 OLEAUT32 C:\Windows\system32\OLEAUT32.dll
76300000 76357000 SHLWAPI C: \ Windows \ system32 \ SHLWAPI.dll
76360000 76401000 RPCRT4 C: \ Windows \ system32 \ RPCRT4.dll
7641000 77059000 SHELL32 C: \ Windows \ system32 \ SHELL32.dll
77240000 772ec000 msvcrt C:\Windows\system32\msvcrt.dll
774b0000 7754d000 USP10 C: \ Windows \ system32 \ USP10.dll
77550000 77624000 kernel32 C: \ Windows \ system32 \ kernel32.dll
77630000 7776c000 ntdll C: \ Windows \ SYSTEM32 \ ntdll.dll
77770000 7778f000 IMM32 C:\Windows\system32\IMM32.DLL
777b0000 777ba000 LPK C: \ Windows \ system32 \ LPK.dll
777c0000 77860000 ADVAPI32 C:\Windows\system32\ADVAPI32.dll

Puoi anche scoprire l'indirizzo di caricamento per un modulo specifico usando il comando "lmf m":

0: 005> lmf m kernel32
inizio fine nome modulo
77550000 77624000 kernel32 C: \ Windows \ system32 \ kernel32.dll

Puoi anche ottenere informazioni sull'intestazione dell'immagine di un modulo specifico usando l'estensione!Dh ( Punto esclamativo indica un'estensione):

0: 005>!Dh kernel32

Tipo di file: DLL
VALORI INTESTAZIONE FILE
macchina 14C (i386)
4 numero di sezioni
4A5BDAAD data e ora lun lug 13 21:09:01 2009

0 puntatore file alla tabella dei simboli
0 numero di simboli
E0 dimensione dell'intestazione opzionale
2102 caratteristiche
eseguibile
word machine a 32 bit
DLL

VALORI INTESTAZIONE OPZIONALI
10B magia #
9.00 versione linker
C4600 dimensione del codice
C800 dimensione dei dati inizializzati
0 dimensione dei dati non inizializzati
510C5 indirizzo del punto di ingresso
1000 basi di codice
----- nuovo -----
77550000 base di immagini
Allineamento di 1000 sezioni
200 file di allineamento
3 sottosistema (interfaccia utente grafica di Windows)
Versione del sistema operativo 6.01
Versione immagine 6.01
6.01 versione del sottosistema
Dimensione dell'immagine D4000
800 dimensioni di intestazioni
D5597 checksum
00040000 dimensione della riserva di stack
00001000 dimensione dello stack commit
0010000 dimensione della riserva di heap
00001000 dimensione dell'heap commit
140 caratteristiche DLL
Base dinamica
Compatibile NX
B4DA8 [A915] indirizzo della directory di esportazione
BF6C0 [1F4] indirizzo della Directory di importazione
C7000 [520] indirizzo di Resource Directory
0 [0] indirizzo della directory delle eccezioni
0 [0] indirizzo della directory di sicurezza
C8000 [B098] indirizzo della directory di riposizionamento base
C5460 [38] indirizzo della directory di debug
0 [0] indirizzo della Directory di descrizione
0 [0] indirizzo della directory speciale
0 [0] indirizzo della directory di archiviazione dei thread
816B8 [40] indirizzo della directory di configurazione del carico
278 [408] indirizzo della directory di importazione associata
1000 [DE8] indirizzo della directory della tabella degli indirizzi di importazione
0 [0] indirizzo della directory di importazione ritardata
0 [0] indirizzo della directory di intestazione COR20
0 [0] indirizzo della rubrica riservata

INTESTAZIONE SEZIONE # 1
.testo nome
C44C1 dimensione virtuale
1000 indirizzi virtuali
C4600 dimensione dei dati grezzi
Puntatore di 800 file a dati grezzi

0 numero di traslochi
0 numero di numeri di riga
60000020 bandiere
Codice
(nessun allineamento specificato)
Esegui lettura

Directory di debug (2)
Tipo Dimensione Indirizzo Puntatore
cv 25 c549c c4c9c Formato: RSDS, guid, 2, kernel32.pdb
(10) 4 c5498 c4c98

INTESTAZIONE SEZIONE # 2
.nome dati
Dimensione virtuale FEC
Indirizzo virtuale C6000
E00 dimensione dei dati grezzi
Puntatore file C4E00 a dati grezzi
0 puntatore file alla tabella di rilocazione
0 puntatore di file ai numeri di riga
0 numero di traslochi
0 numero di numeri di riga
C0000040 bandiere
Dati inizializzati
(nessun allineamento specificato)
Leggere scrivere

INTESTAZIONE SEZIONE # 3
.rsrc nome
520 dimensione virtuale
Indirizzo virtuale C7000
600 dimensioni di dati grezzi
Puntatore file C5C00 a dati grezzi
0 puntatore file alla tabella di rilocazione
0 puntatore di file ai numeri di riga
0 numero di traslochi
0 numero di numeri di riga
40000040 bandiere
Dati inizializzati
(nessun allineamento specificato)
Sola lettura

INTESTAZIONE SEZIONE # 4
.reloc nome
B098 dimensione virtuale
Indirizzo virtuale C8000
Dimensione B200 dei dati grezzi
Puntatore file C6200 a dati grezzi
0 puntatore file alla tabella di rilocazione
0 puntatore di file ai numeri di riga
0 numero di traslochi
0 numero di numeri di riga
42000040 bandiere
Dati inizializzati
Scartabile
(nessun allineamento specificato)
Sola lettura

Messaggi ed eccezioni

Dopo la connessione a un processo, viene visualizzato prima un elenco di moduli, quindi potrebbero essere visualizzati altri messaggi. Ad esempio, quando ci aggrappiamo a calc.exe, WinDBG imposta automaticamente un punto di interruzione (che è solo un marcatore utilizzato per fermare l'applicazione). Vengono visualizzate le informazioni sul punto di interruzione:

(da8.b44): Eccezione istruzione Break - codice 80000003 (prima possibilità)

Questo particolare messaggio è un'eccezione, vale a dire un'eccezione di prima possibilità. Essenzialmente, un'eccezione è una condizione speciale che si verifica durante l'esecuzione del programma. Eccezione first-chance significa che il programma si è interrotto immediatamente dopo che l'eccezione è stata generata. Eccezione di seconda possibilità significa che dopo che si è verificata l'eccezione, verranno eseguite alcune operazioni e quindi il programma interromperà il suo lavoro.

Registri

Dopo aver visualizzato messaggi ed eccezioni, il debugger stampa lo stato dei registri del processore. I registri sono variabili speciali all'interno del processore che memorizzano piccoli blocchi di informazioni o tengono traccia dello stato di qualcosa in memoria. Il processore può elaborare le informazioni in questi registri molto rapidamente. Questo è molto più veloce che ottenere ogni volta informazioni dalla RAM sul bus.

Dopo essersi connesso a calc.exe, WinDBG visualizza automaticamente le informazioni sui seguenti registri:

eax = 7ffd9000 ebx = 00000000 ecx = 00000000 edx = 776cd23d esi = 00000000 edi = 00000000
cs = 001b ss = 0023 ds = 0023 es = 0023 fs = 003b gs = 0000 efl = 00000246

Successivamente, puoi duplicare nuovamente queste informazioni usando il comando r:

0: 005> r
eax = 7ffd9000 ebx = 00000000 ecx = 00000000 edx = 776cd23d esi = 00000000 edi = 00000000
eip = 77663540 esp = 02affd9c ebp = 02affdc8 iopl = 0 nv up ei pl zr na pe nc
cs = 001b ss = 0023 ds = 0023 es = 0023 fs = 003b gs = 0000 efl = 00000246
ntdll! DbgBreakPoint:
77663540 cc int 3

Se vogliamo ottenere il valore di un registro specifico, possiamo eseguire il seguente comando:

0: 005> rex
eax = 7ffd9000

Le informazioni da più registri contemporaneamente possono essere ottenute come segue:

0: 005> reax, ebp
eax = 7ffd9000 ebp = 02affdc8

Puntatore all'istruzione

L'ultimo comando riguarda le istruzioni attivate. Qui vengono anche stampate sullo schermo le informazioni, come nel caso del comando r, di ciò che contiene il registro EIP. EIP è un registro che contiene la posizione dell'istruzione successiva che il processore deve eseguire. Ciò che WinDBG visualizza è l'equivalente del comando u eip L1, dopodiché WinDBG va all'indirizzo specificato nel registro EIP, converte questa sezione in codice assembly e la visualizza sullo schermo.

ntdll! DbgBreakPoint:
77663540 cc int 3

resta in contatto

Nei prossimi articoli, vedremo come utilizzare WinDBG in un ambiente live: punti di interruzione, debug passo dopo passo e scansioni della memoria. Non cambiare! J.

Questi tipi di guasti sono generalmente associati a un driver difettoso che può essere difficile da capire. Tuttavia, il sistema di tracciamento dei bug migliorato in Windows Vista (e non solo in Vista!) può spesso portare a un file problematico. Di conseguenza, la maggior parte delle persone smette di cercare freneticamente di lavorare su un computer instabile, salvando documenti con regolarità paranoica e sperando per il meglio.

In Windows va in crash di solito viene creato un cosiddetto “memory dump”. Quest'ultimo può essere studiato con il debugger gratuito Strumento di Windows Strumenti di debug, che possono indirizzarti alla fonte del problema. Pertanto, tutto ciò che devi fare è:

Scarica te stesso uno strumento di debug

Puoi scaricare gli strumenti di debug di Windows direttamente dal sito Web di Microsoft. Il programma funziona con molti sistemi operativi da Windows NT 4 a Windows 2008, quindi non dovresti avere problemi con esso. Sì, non si può dire che sia stabile sotto Windows 7 RC, ma secondo i nostri test funziona ancora. Pertanto, anche un tentativo di diagnosticare il problema da Windows 7 RC potrebbe avere esito positivo.

Configura il tuo sistema

È necessario che durante gli arresti anomali il computer crei dump della memoria, che serviranno in seguito come fonte di informazioni per il debugger. Pertanto, è importante che Windows sia configurato per generare dump. Per personalizzare il tuo sistema operativo, fai clic su clic destro mouse sul computer (Computer) e selezionare Proprietà (Proprietà). Quindi fare clic sulla scheda Impostazioni di sistema avanzate, individuare la sottosezione Impostazioni di avvio e ripristino e assicurarsi che il parametro Scrivi informazioni di debug sia impostato su Dump memoria kernel ) o Dump memoria completa.

Quindi, fai clic su Start, vai su Tutti i programmi, seleziona Strumenti di debug e avvia WinDbg. Nel programma, vai al menu File e seleziona Percorso file simboli ... Quindi scrivi la seguente riga nella finestra che si apre:

SRV * c: \ simboli * http: //msdl.microsoft.com/download/symbols

Quest'ultimo definisce il percorso di dati speciali, i cosiddetti "simboli", che possono aiutare lo strumento di debug a identificare il file difettoso.

Dopo aver inserito la riga, fare clic sul pulsante OK. Successivamente, quando si lavora con il debugger, questa riga scaricherà i simboli da msdl.microsoft.com e li salverà nella cartella c:\symbols.

Risolvi il tuo problema

Ora attendi il prossimo arresto anomalo con schermata blu e il successivo completamento del riavvio del computer. Quindi eseguire nuovamente WinDbg (gli utenti di Vista devono eseguire il programma come amministratore), fare clic sul menu File, selezionare Open Crash Dump, aprire il file \ Windows \ MEMORY.DMP e il programma inizierà immediatamente ad analizzarlo.

Sfortunatamente, WinDbg fornisce pochissime informazioni su ciò che fa, quindi potresti persino pensare che il programma sia bloccato. Tuttavia, aspetta. Capire, analizzare, diciamo, 4 GB di memoria non è molto computer potente può richiedere del tempo, fino a ore. Pertanto, sii paziente ed è meglio lasciare l'analisi durante la notte.

Tuttavia, di solito il risultato si ottiene in pochi minuti. Ciò è evidenziato dalla riga dell'analizzatore dell'errore Bugcheck Analysis, che riporta qualcosa come "Probabilmente causato da: UACReplace.sys". Tradotto in russo, significa che il problema potrebbe essere causato dal file UACReplace.sys. Inseriscilo in una barra di ricerca come Google e scoprirai la sua vera origine. In particolare, se appartiene a uno dei programmi che hai installato o driver installato quindi puoi semplicemente provare ad aggiornare lei o lui. Forse questo risolverà i problemi che stai riscontrando.

Va detto che di tanto in tanto WinDbg non può nominare affatto il file o seleziona semplicemente una delle DLL di Windows. Se questo è successo per te, fai clic sulla finestra di comando sopra la barra di stato e digita il comando:

Quindi premere Invio. Questo ti fornirà un rapporto più dettagliato, che potrebbe contenere informazioni su possibili ragioni i tuoi guai.

Se questa volta non sei fortunato, non disperare. Il debug è piuttosto difficile, anche per gli esperti. Quindi basta chiudere WinDbg ed eseguire di nuovo l'analizzatore dopo il prossimo arresto anomalo. Forse questo ti darà qualche informazione in più. Buona fortuna!