Kernel Debugging, prepariamoci..

Salve a tutti.

Come avevo promesso in un altro post, oggi vedremo come si può iniziare a fare Kernel Debugging.

Il Kernel Debugging è di solito l’ultima spiaggia per uno sviluppatore di applicazioni in user mode, mentre è il pane quotidiano per chi realizza device driver e componenti che interagiscono e si integrano col sistema operativo. A volte, può essere molto utile.

Il Kernel Debugging si può fare in diversi modi: in quello tradizionale si utilizzano due macchine fisiche, il target, la macchina debuggata e il debugger, quella dove gira il kernel debugger, collegate via cavo null modem o via Firewire 1394 o via USB.
Al giorno d’oggi, grazie alle tecnologie di virtualizzazione, è possibile redirigere la porta COM di un macchina virtuale su una pipe e collegare il debugger alla pipe.

Ci concentriamo quindi per semplicità su quest’ultimo e più moderno modo, vedendo step by step come utilizzare una Virtual Machine configurandola per poter essere collegata ad un Kernel Debugger.

Cosa serve:

- un sistema operativo che supporti Hyper-v, tipo Windows Server 2008 R2 (vanno bene anche Virtual PC o VMWare)

- una virtual machine del sistema operativo che volete debuggare, configurata per il Kernel Debugging

- Windbg. Ovviamente nella “bitness” del sistema operativo che si andrà a debuggare.
Se il sistema target è 32 bit, si userà windbg a 32 bit, se è a 64 si userà la versione x64.

- i simboli di debug del sistema operativo target, nonchè quelli dell’applicazione che volete debuggare

Alla fine si dovrebbe arrivare a vedere questa situazione: Windbg collegato alla Virtual Machine ferma al breakpoint.

Tralascio l’installazione di WIndows Server 2008 R2 con Hyper-v e di una Virtual Machine, perchè ritengo ci siano già una infinità di post su internet che spiegano come fare. Vorrei guidarvi al Setup di Windbg, e ai primi passi con questo, perchè ritengo sia la parte più interessante.. quella che fa la differenza..

Nel caso della bitmap sopra, la VM è di Vista SP2 a 32 bit. Quindi il Windbg da usare sarà quello a 32 bit. Il server su cui gira il tutto è a 64 bit, quindi non ci sono problemi nell’eseguire Windbg a 32 bit sul server a 64. Anzi, di solito, su macchine a 64 bit installo sempre entrambe le versioni di Windbg, in modo da poter debuggare processi a 32 e 64 bit, ognuno col suo debugger.

Download e installazione di Windbg.

X86(32bit)

Installate l’ultima versione di Windbg da questo link: http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx in C:\Debuggers.

X64 (64 bit)

Installate l’ultima versione di Windbg da questo link: http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspx in C:\Debuggers64.

I simboli.

Se la macchina host è collegata ad Internet, potete anche configurare i simboli pubblici, eseguendo Windbg, menu File->Symbol File Path, con questa stringa:

srv*C:\Symbols*http://msdl.microsoft.com/download/symbols

In questo modo, i simboli pubblici verranno scaricati dal Symbol server pubblico di Microsoft e scaricati nella cache locale in “C:\Symbols”.
Se non avete accesso ad internet, potete scaricare i simboli pubblici del sistema oeprativo che state usando direttamente da qui: http://www.microsoft.com/whdc/DevTools/Debugging/symbolpkg.mspx

I simboli di debug privati delle vostre applicazioni, dovete aggiungerli allo store. I simboli vanno aggiunti nello store non a caso, cioè semplicemente copiando i file nel folder, ma usando un tool, installato da Windbg, chiamato Symstore:

symstore add /f c:\Project\Myapp\Bin\debug\*.pdb /s c:\symbols /t "Symbols for MyApp"

Questo creerà la struttura necessaria dei folder, sotto C:\Symbols, ed eviterà il conflitto delle versioni consentendo di debuggare più versioni contemporaneamente.

Mi raccomando, quando compilate in Debug o in Release mode, create sempre i simboli e conservateli gelosamente. Ad ogni ricompilazione i simboli generati saranno diversi, quindi se doveste mai dover debuggare una specifica versione rilasciata, dovrete usare i simboli di quella specifica versione. Eseguibili (vale anche le dll) e simboli devono sempre essere allineati. Non si può debuggare un eseguibile o una dll con i simboli di un altra versione.

Configurazione della VM per il Kernel Debugging.

FIno a Windows XP, per abilitare il sistema operativo al Kernel Debugging, era sufficiente aggiungere al file Boot.ini i vari flag che abilitavano il Kernel Debugging, la porta COM da usare e la velocità della stessa. Generalmente si aggiungeva questa stringa alla riga di boot.ini di default:

/debug /debugport=com1 /baudrate=115200

Tipo:

multi(0)disk(0)rdisk(0)partition(1)\WINNT="Microsoft Windows XP" /fastdetect /debug /debugport=com1 /baudrate=115200

In Vista e successivi, il Kernel debugging può essere eseguito anche via USB o Firewire, e si abilita usando l’utility di sistema BCDEDIT.

bcdedit /debug {<guid>} <ON | OFF>
bcdedit /dbgsettings SERIAL DEBUGPORT:1 BAUDRATE:115200 
Dove il  {<GUID>} è il guid per il "Windows Boot Loader" nel BCD Store.

Ad esempio:

C:\>bcdedit /enum /v
Windows Boot Manager
--------------------
identifier {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device partition=C:
description Windows Boot Manager
locale en-US
inherit {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
default {f7ca7cca-ee65-11dd-aea9-9654f2a57af9}
displayorder {f7ca7cca-ee65-11dd-aea9-9654f2a57af9}
toolsdisplayorder {b2721d73-1db4-4c62-bf78-c548a880142d}
timeout 30
Windows Boot Loader
-------------------
identifier {f7ca7cca-ee65-11dd-aea9-9654f2a57af9}
device partition=C:
path \Windows\system32\winload.exe
description Microsoft Windows Vista
locale en-US
inherit {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
osdevice partition=C:
systemroot \Windows
resumeobject {f7ca7ccb-ee65-11dd-aea9-9654f2a57af9}
nx OptIn

C:\>bcdedit /debug {f7ca7cca-ee65-11dd-aea9-9654f2a57af9} ON

C:\>bcdedit /dbgsettings SERIAL DEBUGPORT:1 BAUDRATE:115200

o anche semplicemente con

C:\>bcdedit /debug ON

Verranno in questo caso usati i default, che sono il GUID di default e COM1 a 115200 baud.

Configurazione della redirezione su pipe della porta seriale della VM.

Una delle feature di Hyper-v è quella della possibile redirezione della porta seriale su una pipe. Questa incontra una delle specificità di Windbg, che è proprio quella di poter funzionare come Kernel Debugger collegato ad una pipe.

Quindi, nella configurazione della VM in Hyper-v, andremo a modificare i settings della VM in modo da redirigere l’output della porta seriale su una pipe, e in Windbg andremo a configurare il Kernel Debugger per collegarsi a quella pipe creata da Hyper-v.

In Hyper-v manager, selezionate la VM che volete debuggare, andate in Settings, e collegate la COM1 a una pipe di cui sceglierete il nome. Nel mio caso, ho scelto VistaDebug.

Il Winbdg va avviato “As Administrator”, perchè in Windows Server 2008 le pipe sono oggetti “securable” e quelle globali, come quelle create da Hyper-v sono accessibili solo agli amministratori.

Fatto questo, in Windbg, dal Menu File –> Kernel Debug, scegliete il Tab COM, mettete il segno di spunta a Pipe, indicando quindi di non usare la porta COM, ma una pipe; selezionate Reconnect, così che dopo un reboot, si ricollegherà, e in Port mettete il nome della pipe creata in Hyper-v: \\.\pipe\VistaDebug .

Fatto tutto ciò siamo pronti ad eseguire il nostro primo Kernel Debugging.

Ma questo sarà il tema della prossima puntata.. non voglio soffocarvi di informazioni..

 

Alla prossima!

Mario Raccagni
Senior Support Engineer
Platform Development Support Team