NOTA: la documentazione del Windows Driver Kit (WDK) ed i software citati nel presente articolo sono disponibili solo in lingua Inglese.

 

---

Introduzione

Molti utenti non sanno che esiste una "versione speciale" di Windows che è fornita solo agli abbonati MSDN e destinata (per il modo "speciale" in cui è costruita) principalmente agli sviluppatori di driver di periferica: si tratta della debug (o checked) build.

↑ Torna all'inizio

Cosa è la Checked Build

La checked build (disponibile solo con un abbonamento MSDN Professional o superiore) è una ricompilazione del codice sorgente di Windows con un flag definito in fase di compilazione chiamato “DBG" (un simbolo del preprocessore) definito, che provoca l'inserimento in fase di compilazione di codice di debugging condizionale e di tracing. Inoltre, per rendere più semplice la comprensione del codice macchina e la lettura dei messaggi di trace, non viene eseguito il post-processing dei files binari di Windows per ottimizzare il layout del codice con lo scopo di ottenere una maggiore velocità di esecuzione.
La checked build è fornita principalmente per supportare gli siluppatori di drivers di periferica in quanto esegue un controllo più severo degli errori sulle chiamate di funzione in modalità kernel eseguite dai driver di periferica o da altro codice di sistema: ad esempio, se un driver (o una qualche altra porzione di codice in modalità kernel) dovesse eseguire una chiamata non valida ad una funzione di sistema che sta controllando dei parametri (come l'acquisizione di uno spinlock ad un livello di interrupt errato), il sistema arresterà l'esecuzione appena il problema sarà individuato piuttosto che consentire che alcune strutture dati siano corrotte e che il sistema possa successivamente andare in crash.
Come scritto da Walter Oney nel libro "Programming the Microsoft Windows Driver Model, 2nd Edition", una delle cose che lo sviluppatore può fare è fornire codice aggiuntivo che sarà eseguito solamente nella checked build scrivendo qualcosa di simile a quanto riportato di seguito

#if DBG
    // extra debugging code
    ...
#endif

Come precedentemente detto, il simbolo "DBG" vale "1" negli ambienti con build checked, mentre vale "0" negli ambienti con build free: questo frammento di codice sarà eseguito solo negli ambienti checked build.

↑ Torna all'inizio

Determinare il tipo di build del sistema

I supporti di installazione che contengono una checked build sono chiaramente etichettati con "Debug/Checked Build". Oltre a ciò, l'utente ha a disposizione due modi per determinare quale build di Windows è in esecuzione: il modo più semplice è aprire il Visualizzatore eventi (Start -> Esegui..., digitare "eventvwr.msc" e premere INVIO) e cercare gli eventi con ID 6009: questi eventi sono registrati durante ogni avvio del sistema ed indicano la versione del sistema operativo, il numero di build, il livello di service pack ed altre informazioni pertinenti relative al sistema.
Nelle figure di seguito, si può vedere questo evento registrato nella fase di avvio di Windows startup (la figura 1-a si riferisce ad un'installazione in lingua italiana di Windows XP Professional x86 Service Pack 3 in esecuzione su una CPU Intel Pentium III-M; la figura 1-b si riferisce ad un'installazione in lingua inglese di Windows 7 Ultimate x64 Service Pack 1 in esecuzione su una CPU Intel Mobile Core 2 Duo T7800) insieme all'indicazione del tipo di build.

Figura 1-a: Evento ID 6009 in Windows XP Professional x86 SP3.

Figura 1-b: Evento ID 6009 in Windows 7 Ultimate x64 SP1.

Come si vede, entrambi i sistemi eseguono una build free (o retail) di Windows.
L'altro modo disponibile per determinare se il sistema sta eseguendo una build checked è interrogare il valore della proprietà Debug della classe Win32_OperatingSystem disponibile in Windows Management Instrumentation (WMI). Il libro "Windows Internals, 5th Edition" fornisce il seguente esempio di script Visual Basic che dimostra come visualizzare il valore di questa proprietà:

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
 & "{impersonationLevel=impersonate}!\\" & strComputer _
 & "\root\cimv2")
Set colOperatingSystems = objWMIService.ExecQuery _
 ("SELECT * FROM Win32_OperatingSystem")
For Each objOperatingSystem in colOperatingSystems
    Wscript.Echo "Caption: " & objOperatingSystem.Caption
    Wscript.Echo "Debug: " & objOperatingSystem.Debug
    Wscript.Echo "Version: " & objOperatingSystem.Version
Next

Per provare questo script, digitarlo e salvarlo in un file. Di seguito è riportato l'output risultante dall'esecuzione dello script su un'installazione (in lingua inglese) di Windows Vista:

C:\>cscript osversion.vbs
Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation. All rights reserved.

Caption: Microsoft Windows Vista
Debug: False
Version: 6.0.6000

Il sistema non sta eseguendo una build checked, poichè il valore del flag Debug visualizzato è False.

↑ Torna all'inizio

Cosa accade all'interno

La maggior parte del codice aggiuntivo presente nei files binari della build checked è il risultato dell'utilizzo della macro ASSERT, definita nel file header Ntddk.h del Windows Driver Kit (WDK) e descritta nella documentazione del WDK stesso. Questa macro esamina una condizione (come la validità di una struttura dati o di un parametro) e, se l'espressione ha valore FALSE, chiama la funzione in modalità kernel RtlAssert, che a sua volta chiama DbgPrintEx per inviare il testo di un messaggio di debug ad un apposito buffer: se al sistema è connesso un debugger del kernel, questo messaggio viene visualizzato ed automaticamente seguito da un prompt che chiede all'utente come procedere in merito al fallimento dell'asserzione (interrompere, ignorare, terminare il processo o il thread); se il sistema non è stato avviato con il debugger del kernel (utilizzando l'opzione di debug presente nel Boot Configuration Database — BCD) e nessun debugger del kernel è connesso al sistema, il fallimento di un test ASSERT provocherà un bugcheck.
Per avere una lista delle verifiche ASSERT eseguite da alcune delle routines di supporto del kernel, consultare la sezione “Checked Build ASSERTs” nella documentazione del WDK. Per avere una lista ed una spiegazione di alcuni dei breakpoints comuni e dei messaggi stampati da DbgPrintEx che un driver può incontrare negli ambienti con checked build, consultare la sezione "Checked Build Breakpoints and Messages" nella documentazione del WDK.

↑ Torna all'inizio

Per chi è utile la Checked Build

La checked build è utile anche per gli amministratori di sistema per via del tracing informativo aggiuntivo e dettagliato che può essere abilitato per alcuni componenti (per istruzioni dettagliate, leggere l'articolo 314743 della Microsoft Knowledge Base, intitolato "Attivazione dell'analisi del debug dettagliato in diversi driver e sottosistemi"). Quest'informazione di output è inviata ad un buffer interno per i messaggi di debug utilizzando la funzione DbgPrintEx precedentemente menzionata. Per visualizzare i messaggi di debug, si può attaccare un debugger del kernel al sistema (opzione che richiede l'avvio del sistema in modalità di debugging), utilizzare il comando !dbgprint mentre si esegue il debugging locale del kernel, or utilizzare il programma DebugView di Windows Sysinternals. Infine, la checked build può essere utile anche per testare del codice in modalità utente per via della differenza nella temporizzazione del sistema (questo per via dei controlli aggiuntivi eseguiti all'interno del kernel e per la mancanza delle ottimizzazioni nella compilazione dei componenti). Spesso, i problemi di sincronizzazione negli ambienti multithread sono relativi a specifiche condizioni di temporizzazione. Svolgendo i test su un system su cui è in esecuzione la checked build (o, quantomeno, la build checked del kernel e dell'Hardware Abstraction Layer), la differenza di temporizzazione del sistema può far emergere dei bug latenti di temporizzazione che non si verificano su un normale sistema retail.

↑ Torna all'inizio

Controlli effettuati dalla Checked Build

La checked build include un certo numero di controlli di debugging che non sono solitamente presenti nel sistema, inclusi:

• Controlli di validazione dei parametri
  Questi controlli assicurano che il codice del sistema operativo sia eseguito normalmente con il minore overhead possible. Come risultato, i sistemi operativi NT-based implementano una policy per a quale tutti i componenti eseguiti in kernel-mode, compresi i drivers, "si fidano" implicitamente l'uno dell'altro. Quindi, i parametri passati tra i componenti in kernel-mode (come i parametri passati alle chiamate di funzione) sono tipicamente soggetti ad una minima validazione.
• Controlli interni della correttezza e della consistenza del sistema operativo
  Tipicamente questi controlli verificano la correttezza degli algoritmi chiave e delle strutture dati del del sistema operativo.
• Controlli informativi e tracing dell'output
  Questi controlli ed il risultante output visualizzato nel debugger sono progettati per fornire assistenza durante il debugging dei drivers o di altri componenti a livello di sistema. Spesso, questi tipi di controlli devono essere abilitati individualmente impostando dei flag di debug (tipicamente tramite il debugger) all'interno del componente interessato. L'esistenza di questi controlli ed il relativo output di debug può variare in ogni versione del sistema operativo ed è documentata negli articoli della Microsoft Knowledge Base.

↑ Torna all'inizio

Simboli di debug e service packs

Come si è probabilmente supposto, non è possibile utilizzare i simboli di debug standard per le build free nè installare i service packs per le build free su un'installazione con checked build: è necessario scaricare ed installare le versioni checked dei simboli di debug e dei service packs.

↑ Torna all'inizio

Come installarla

Non è necessario installare l'intera checked build per avvantaggiarsi della versione debug del sistema operativo: è sufficiente copiare le versioni checked dell'immagine del kernel (Ntoskrnl.exe) e l'appropriato HAL (Hal.dll) su una normale istallazione retail. Il vantaggio di questo approccio è che i driver di periferica e le altre parti di codice kernel sono sottoposte al controllo rigoroso della checked build senza dover eseguire le più lente versioni debug di tutti i componenti presenti nel sistema. Per avere istruzioni dettagliate su come realizzare questa configurazione, consultare le sezioni “Installing Just the Checked Operating System and HAL for Windows XP and Windows Server 2003” o "Installing Just the Checked Operating System and HAL for Windows Vista and Later" nella documentazione del WDK.

↑ Torna all'inizio

---

Altre lingue

Questo articolo è disponibile anche nelle seguenti lingue:

English (en-US)

• Windows Checked Build (en-US)