L’analyse manuelle avec kd

(souvent baptisé WinDebug)
et Kd (baptisé i386kd dans les précédentes versions des nouveaux outils de débogage).
Ces outils comprennent des jeux de commandes identiques et la même fonction de
vidage de données, tandis que Kd est un programme à  lignes de commandes. Je recommande
d’utiliser WinDbg, qui permet de copier facilement les valeurs et d’utiliser des
sous-fenêtres pour afficher simultanément davantage d’informations.

Pour lancer WinDbg pour analyser un vidage sur incident, tapez :



Windbg -z [memory dump file] -y [symbols directory]



à  l’invite de commande. (Si vous avez défini la variable _NT_SYMBOL_PATH, vous
pouvez omettre l’option -y). WinDbg s’exécute et présente une vue comme celle
de la Figure 7. Vous pouvez à  présent entrer un certain nombre de commandes de
débogage qui montreront l’état des divers aspects du système au moment de l’incident.
L’environnement du débogage consiste en trois types de commandes : les commandes
de débogage intégrées, qui n’ont pas de préfixe ; les commandes à  points, qui
ont un point (.) comme préfixe ; et les commandes bang, qui ont un point d’exclamation
(!) comme préfixe).





La commande de débogage intégrée la plus utile est Dd, qui vide une plage de mémoire.
La commande dd esp vide ce que désigne le registre de l’indicateur de pile (également
baptisé registre esp). Mais, à  moins d’être familiarisé avec le langage assembleur
x86, les vidages esp ne sont pas utiles. Pour accéder à  l’Aide en ligne des commandes
de débogage intégrées, utilisez la commande  » ? « .



Les commandes à  points servent à  charger et décharger des DLL enfichables de débogage
(également baptisées DLL d’extension de débogage) et à  contrôler le comportement
d’une cible de débogage active. Une cible active est un système opérationnel que
l’on débogue activement. Tout comme les commandes intégrées, les commandes à  points,
soit ne facilitent pas l’analyse du vidage sur incident, soit demandent des connaissances
avancées.



Les DLL d’extension de débogage mettent en oeuvre les commandes bang. WinDbg et
Kd chargent automatiquement la DLL d’extension de débogage du noyau de base kdextx86.dll,
qui comporte des commandes permettant d’afficher des informations sur les divers
objets du noyau Windows 2000 ou Windows NT. Commencez par recueillir un certain
nombre de données initiales en exécutant la commande !processpid. Cette commande
vide des informations sur le processus en cours d’exécution au moment de l’incident.
Pour obtenir une liste complète des processus, utilisez la commande !process 0
0. La commande !thread tid vide les données sur le thread qui était en cours d’exécution,
y compris le chemin de sa pile. La simple détermination du processus en cours
d’exécution au moment de l’incident, peut déjà  fournir un indice utile sur la
cause de l’incident, et le chemin de la pile peut très bien désigner un driver
responsable de l’incident. Si !thread tid est exécuté sur un vidage généré avec
BSOD, le chemin de la pile identifie crashdd.sys.



Si un texte, comme TrapFrame@8013eee8 apparaît à  droite de la ligne du chemin
de la pile, exécutez la commande .trap nnnn, sachant que nnnn est le nombre hexadécimal
qui apparaît après le & dans le texte (8013eee8 dans l’exemple). Puis, exécutez
la commande Kv. WinDbg montre le chemin de la pile d’un bloc d’interruption, qui
reflète la pile avant la prise de contrôle par une fonction de gestion d’interruption.
WinDbg ne peut pas toujours afficher un chemin précis de la pile, mais, lorsqu’il
le fait, le chemin de la pile du bloc d’interruption révèle le véritable chemin
ayant conduit à  l’incident. N’hésitez pas à  rechercher dans les Connaissances
de base les noms des drivers apparaissant dans le chemin de la pile, vous pouvez
toujours tomber, par chance, sur un problème traité par Microsoft. Consultez aussi
l’Aide de WinDbg : des astuces avancées qui vous aideront à  déterminer vous-même
une analyse du chemin de la pile.



La commande !drivers vide une liste de pilotes à  charger contenant une partie
des informations affichées par Windows NT 4.0 sur les écrans bleus. Elle affiche
les dates de création des pilotes, qui peuvent mettre en évidence les pilotes
périmés. Procurez-vous les mises à  jour des anciens pilotes. Pour déterminer l’éditeur
d’un pilote, il suffit d’afficher les propriétés du fichier du pilote dans Windows
Explorer (la plupart des pilotes sont stockés dans le répertoire \winnt\system32\drivers)
; les informations sur la version mentionnent notamment le copyright du développeur
et parfois une description du pilote.

Il existe de nombreuses autres commandes bang (la commande !help en donne une
liste complète), mais j’ai présenté celles qui peuvent s’utiliser sans connaissances
avancées des fonctions internes de Windows 2000 ou NT. Le fichier d’Aide de WinDbg
décrit diverses options supportées par les commandes bang, les commandes à  point
et les commandes intégrées.