Condividi tramite

Introduzione al debug di Windows

Questo articolo illustra come iniziare a eseguire il debug di Windows con WinDbg e altri strumenti di debug. Si apprenderà come:

  • Installare il debugger e configurare sistemi host e di destinazione
  • Configurare l'ambiente di debug
  • Tecniche di debug essenziali per scenari in modalità kernel e in modalità utente

Nota: Se invece si vuole analizzare un dump di arresto anomalo del sistema, vedere Analizzare i file di dump di arresto anomalo del sistema usando WinDbg.

Per iniziare a eseguire il debug di Windows, completare la procedura seguente.

1. Installare il debugger di Windows

Installare WinDbg per avviare il debug di applicazioni e driver Windows. Per i passaggi di installazione dettagliati, vedere Installare WinDbg.

2. Identificare i sistemi host e di destinazione

Due sistemi computer separati vengono in genere usati per il debug perché l'esecuzione delle istruzioni sul processore viene in genere sospesa durante il processo. Il debugger gira sul sistema host e il codice che si vuole eseguire il debug gira sul sistema di destinazione.

host <--------------------------------------------------> destinazione

Screenshot di un diagramma che mostra una doppia freccia che collega i sistemi host e di destinazione per il debugging.

In alcune situazioni, è possibile usare una macchina virtuale come secondo sistema. Ad esempio, un PC virtuale potrebbe essere eseguito sullo stesso PC in cui il codice deve essere sottoposto a debug. Tuttavia, se il codice comunica con hardware di basso livello, l'uso di un PC virtuale potrebbe non essere l'approccio migliore. Per ulteriori informazioni, vedi Configurazione del debug di rete di una macchina virtuale - KDNET.

3. Determinare il tipo di debugger: modalità kernel o modalità utente

Successivamente, è necessario determinare se usare il debug in modalità kernel o in modalità utente.

  • Il sistema operativo e i programmi con privilegi vengono eseguiti in modalità kernel . Il codice in modalità kernel ha l'autorizzazione per accedere a qualsiasi parte del sistema e non è limitato come il codice in modalità utente. Il codice in modalità kernel può accedere a qualsiasi parte di qualsiasi altro processo in esecuzione in modalità utente o kernel. Gran parte delle funzionalità principali del sistema operativo e molti driver di dispositivo hardware vengono eseguiti in modalità kernel.

  • Le applicazioni e i sottosistemi nel computer vengono eseguiti in modalità utente . I processi eseguiti in modalità utente operano all'interno dei propri spazi di indirizzi virtuali. Sono limitati a ottenere l'accesso diretto a molte parti del sistema, tra cui hardware di sistema, memoria non allocata per il loro uso e altre parti del sistema che potrebbero compromettere l'integrità del sistema. I processi eseguiti in modalità utente sono effettivamente isolati dal sistema e da altri processi in modalità utente, in modo che non possano interferire con queste risorse.

Se l'obiettivo è eseguire il debug di un driver, determinare se il driver è un driver in modalità kernel o un driver in modalità utente. I driver di Windows Driver Model (WDM) e Kernel-Mode Driver Framework (KMDF) sono entrambi driver in modalità kernel. Come suggerisce il nome, i driver del User-Mode Driver Framework (UMDF) sono driver in modalità utente.

Per alcuni problemi, può essere difficile determinare in quale modalità viene eseguito il codice. In tal caso, potrebbe essere necessario selezionare una modalità e visualizzare le informazioni disponibili in tale modalità. Alcuni problemi richiedono l'uso del debugger sia in modalità utente che in modalità kernel.

A seconda della modalità in cui si esegue il debug, potrebbe essere necessario configurare e usare i debugger in modi diversi. Alcuni comandi di debug funzionano allo stesso modo in entrambe le modalità e alcuni comandi funzionano in modo diverso.

Passaggi successivi per il debug in modalità kernel

Passaggi successivi per il debug in modalità utente

4. Scegliere l'ambiente del debugger

Il debugger WinDbg funziona correttamente nella maggior parte delle situazioni, ma in alcuni casi potrebbe essere necessario usare un altro debugger, ad esempio debugger della console per l'automazione o Visual Studio. Per altre informazioni, vedere Ambienti di debug.

5. Determinare come connettere l'obiettivo e l'host

In genere, si connettono sistemi di destinazione e host usando una rete Ethernet. Se si stanno eseguendo i primi lavori di avviamento o se non si dispone di una connessione Ethernet su un dispositivo, sono disponibili altre opzioni di connessione di rete. Per altre informazioni, vedere questi articoli:

6. Scegliere strumenti di debug a 32 bit o a 64 bit

Se è necessario un debugger a 32 bit o a 64 bit, dipende dalla versione di Windows eseguita nei sistemi host e di destinazione e dal debug di codice a 32 bit o a 64 bit. Per altre informazioni, vedere Scelta di strumenti di debug a 32 o a 64 bit.

7. Configurare i simboli

Per usare tutte le funzionalità avanzate fornite da WinDbg, è necessario caricare i simboli appropriati. Se non si configurano correttamente i simboli, si ricevono messaggi che indicano che i simboli non sono disponibili quando si tenta di usare la funzionalità che dipende dai simboli. Per altre informazioni, vedere Simboli per il debug di Windows.

8. Configurare il codice sorgente

Se l'obiettivo è eseguire il debug di codice sorgente personalizzato, è necessario configurare un percorso per il codice sorgente. Per altre informazioni, vedere Percorso di origine.

9. Acquisire familiarità con l'operazione del debugger

La sezione dell'operazione del debugger di questa documentazione descrive l'operazione del debugger per varie attività. Ad esempio, Mantenere un file di log in WinDbg descrive come WinDbg può scrivere un file di log che registra la sessione di debug.

10. Acquisire familiarità con le tecniche di debug

Tecniche di debug standard si applicano alla maggior parte degli scenari di debug ed esempi includono l'impostazione delle interruzioni, l'ispezione dello stack di chiamate e l'individuazione di perdite di memoria. Tecniche di debug specializzate si applicano a specifiche tecnologie o tipi di codice. Ad esempio, il debug Plug and Play, il debug del KMDF e il debug dell'RPC.

11. Usare i comandi di riferimento del debugger

È possibile usare diversi comandi di debug mentre si lavora nel debugger. Per ottenere assistenza su qualsiasi comando durante il debug, usare il .hh comando seguito dal nome del comando.

Esempi:

.hh bp # Get help on breakpoint commands
.hh k # Get help on call stack commands

Per un elenco completo dei comandi disponibili, vedere Informazioni di riferimento sul debugger.

12. Usare le estensioni di debug per tecnologie specifiche

È possibile usare più estensioni di debug per analizzare strutture di dati specifiche del dominio. Per altre informazioni, vedere Estensioni specializzate. Per informazioni su come caricare le estensioni del debugger, vedere Caricamento delle DLL dell'estensione del debugger.

Questa documentazione presuppone che l'utente abbia alcune conoscenze sui componenti interni di Windows principali. Per altre informazioni sugli elementi interni di Windows, tra cui l'utilizzo della memoria, il contesto, i thread e i processi, è possibile esaminare le risorse come Internals di Windows di Paolo Yosifovich, Mark E. Russinovich, David A. Solomon e Alex Ionribu.

14. Esaminare le risorse di debug aggiuntive

Altre risorse includono i libri e i video seguenti:

  • All'interno di Windows Debugging: Strategie Pratiche di Debug e Tracciamento di Tarik Soulami
  • debug avanzato di Windows di Mario Hewardt e Daniel Pravat
  • Defrag Tools serie di video, episodi dal 13 al 29, incentrati su WinDbg

Passaggi successivi

Scegliere la modalità di debug per continuare:

Debug in modalità kernel (per i driver e i componenti del sistema operativo):

Debug in modalità utente (per le applicazioni):

Indicazioni aggiuntive per la configurazione:

  • Last updated on