|
*******************************************************************************
*
*
*
Bugcheck Analysis *
*
*
*******************************************************************************
Use
!analyze -v to get detailed debugging information.
BugCheck
D1, {0, 2, 0, f8b842a4}
***
ERROR: Module load completed but symbols could not be loaded for CRASHDD.SYS
Probably
caused by : CRASHDD.SYS ( CRASHDD+2a4 )
Followup: MachineOwner
---------
Voilà ce que l’on peut obtenir en analysant un dump. Vous
savez, quand vous obtenez des écrans bleus, aussi appelé BSOD (Bleu Screen Of
the Death). Mark Russinovich nous a fait une excellente session sur le sujet.
Je vais essayer de vous en donner les points principaux et vous montrer que
c’est finalement un exercice assez facile.
Mark est l’auteur de nombreux outils que l’on peut trouver
sur http://www.sysinternals.com.
Comme expliqué dans l’article d’hier, Mark crée ses outils
par reverse engineering sans avoir accès au code source. Il a d’ailleurs animé
une session faisant un tour d’horizon de ses meilleurs outils. Au programme, il
y a eu les outils de monitoring (Filemon, Regmon, Process Explorer, TCPView),
d’administration système (la suite PSTools) et les outils liés au système de
fichier (les fameux FAT32 for Windows NT 4.0, NTFSDOS et NTFS for Windows 98).
Tous des outils que je vous recommande chaudement de regarder car ils vous
serviront tous un jour.
Bon, rentrons dans le vif du sujet. La première question que
l’on peut se poser est : pourquoi ses magnifiques fond d’écrans bleus
apparaissent ? Ce n’est pas pour vous sortir de votre fond d’écran
habituel mais pour vous prévenir que quelque chose dans le système tente une
opération qui déstabiliserait le système. Comme dans tous les systèmes
d’exploitation, n’importe quel composant qui tourne dans le mode noyau est
susceptible de faire ce type d’opération. Dans Windows, la principale cause
d’écran bleu est liée aux drivers et aux problèmes matériels. Certains évoquent
également la malédiction de Toutankhamon, mais personnellement, je n’y crois
pas trop.
La seconde question est : A quoi cela sert-il
d’analyser un dump ? Evidemment pour se faire plaisir intellectuellement
et pouvoir se vanter à la machine à café mais surtout pour l’identifier, le
corriger et éviter que le problème réapparaisse.
La troisième question et probablement la plus
importante : comment fait-on ? Pour répondre à cette question, je vous propose
une méthode en 4 étapes pour effectuer une première qualification du problème.
Pour les plus courageux, plongez-vous dans la lecture de l’excellent
« Inside Windows 2000, Thrid Edition » (ISBN 0-7356-1021-5, de Mark
Russinovich et David Solomon), de l’aide de Windbg, les articles de MSDN, du
support technique et la doc des DDK (Device Development Kit).
Première étape : les paramètres permettant de créer les
dump.
Il est nécessaire d’activer quelques paramètres. Pour cela,
propriété du poste de travail puis onglet avancé et bouton paramètre de
Démarrage et récupération.
Il est possible de sélectionner 3 types de dump : image
mémoire partielle (64Ko), image mémoire du noyau et image mémoire complète.
Sauf à vouloir faire une analyse très en profondeur, l’image partielle et
celle du noyau suffisent en première approche.
Une fois paramétré, il ne reste plus qu’à attendre l’écran
bleu. Si vous êtes un peu impatient, utiliser l’outil BSOD de Mark téléchargeable
sur http://www.systernals.com/ntw2k/freeware/bluesave.shtml.
En gros, cet outil charge un driver qui effectue 4 opérations : allocation
de mémoire en mode noyau, libération de cette mémoire, génération d’un IRQL
(interruption logicielle) et accès à la mémoire libérée. Bang, changement de
fond d’écran. Sympa, Mark vous offre en prime le code source de son driver si
vous souhaitez l’améliorer…
Nous voilà donc avec un dump. Voyons maintenant avec quels
outils analyser ce dump.
Deuxième étape : les outils
Microsoft fourni 2 outils indispensables pour analyser les
dump : Windbg (avec une jolie interface graphique) et kd (en ligne de
commande). Ayant 2 mains gauches, je vais utiliser Windbg. Cet outil est téléchargeable
gratuitement sur le site Microsoft http://www.microsoft.com/ddk/debugging.
Je vous recommande de vérifier régulièrement la version disponible de Windbg,
elle est mise à jour très régulièrement. Une fois Windbg installé, il est
nécessaire de paramétrer le chemin d’accès aux symbols (symboles en français
dans le texte) qui permettent notamment de voir quelles sont les fonctions qui
ont été appelée dans la pile, de voir les structures, etc avec leur petit nom
d’origine. La plupart des fonctions et structures du kernel commencent par nt!.
Les symbols sont disponibles en ligne, soit en
téléchargement en package, soit sur les CD des produits, soit en téléchargement
à la volée. C’est cette dernière option que je vous conseille. Pour cela, allez
dans le menu File puis Symbol File Path… puis tapez
srv*c:\symbols*http://msdl.microsoft.com/download/symbols, le tout sans espace.
Cela vous permettra de charger automatiquement les symbols
dont vous avez besoin et les stocker localement dans le répertoire c:\symbols.
Attention, les chargements peuvent être long, les fichiers symbols sont en
général assez gros, au minimum de la taille du fichier binaire. L’avantage de
cette solution est que vous n’avez pas à vous soucier de choisir les bons
symbols, c’est Windbg qui s’en charge pour vous. Quand on sait que les symbols
changent en fonction de l’OS (on peut s’en douter) mais aussi des hotfix et des
service pack, là, ça devient intéressant, surtout quand on ne sait plus quels
hotfix on a installé…
Nous voilà prêt. Passons à l’étape suivante :
l’analyse, celle qui va enfin permettre de savoir quel est ce $*#{@ de problème
qui m’a repeint ma chambre en bleue.
Troisième étape : l’analyse
Pour analyser le dump, nous allons utiliser Windbg. Avant
d’ouvrir un dump, vérifiez que le symbol path est correcte (cf étape
précédente). Ensuite, allez dans le menu file puis Open Crash Dump… et
sélectionnez un fichier .dmp. Suivant les paramètres sélectionnés, le dump ne
se trouve pas au même endroit. Si vous avez laissez les paramètres par défauts,
les minidump sont stockés dans %SystemRoot%\minidump (%SystemRoot% représente
le chemin du répertoire système de Windows). Les dump complets de la mémoire du
noyau ou de la totalité de la mémoire se trouvent directement dans le
répertoire %SystemRoot%.
Je vais prendre comme exemple, un fichier dump de la mémoire
du noyau uniquement généré à l’aide de l’outil de Mark.
A peine ouvert, on obtient cela :
2 fenêtres apparaissent dont une première qui pour un non
développeur paraît un peu barbare. Il s’agit de la pile d’appelle. Fermons
cette fenêtre qui dans une analyse simple ne nous apportera rien. Derrière
cette fenêtre se cache une seconde fenêtre beaucoup plus intéressante :
On peut y voir le résultat d’une analyse faite
automatiquement par Windbg quand il a chargé le dump. Son diagnostique dans
notre cas est une faute commise par un fichier CRASHDD.SYS. Comme indiqué, j’ai
généré ce dump à l’aide de l’outil BSOD de Mark. Comme expliqué plus haut, cet
outil installe un driver qui génère un écran bleu. Ce driver est bien
évidemment CRASHDD.SYS, CQFD. OK, c’est un premier pas mais le plus souvent,
les problèmes ne sont pas si facile à élucider et l’on a besoin de quelques
infos de plus. Comme indiqué dans Windbg, la commande !analyze –v permet
d’obtenir des informations complémentaires. Elle permet par exemple de savoir
ce qui a généré la faute. Dans notre cas cela donne :
DRIVER_IRQL_NOT_LESS_OR_EQUAL
(d1)
An
attempt was made to access a pagable (or completely invalid) address at an
interrupt
request level (IRQL) that is too high. This is usually
caused
by drivers using improper addresses.
If
kernel debugger is available get stack backtrace.
Arguments:
Arg1:
00000000, memory referenced
Arg2:
00000002, IRQL
Arg3:
00000000, value 0 = read operation, 1 = write operation
Arg4:
f8b842a4, address which referenced memory
C’est ce que vous obtiendrez la plupart du temps quand il
s’agit d’un driver qui est en faute.
Suivent ensuite des informations complémentaires. Autre
commande intéressante, la commande !process 0 0 qui permet de lister
l’ensemble des processus présents en mémoire. Dans notre cas, nous retrouverons
facilement le processus BSOD :
PROCESS 80f8bda8 SessionId:
0 Cid: 0f4c Peb: 7ffdf000 ParentCid: 0650
DirBase: 17994000
ObjectTable: e1d724e8 TableSize: 25.
Image: BSOD.EXE
La commande !process 80f8bda8, permet d’obtenir encore
plus d’informations comme par exemple, la mémoire utilisée (utilise pour
détecter les memory leak), les priorités de l’application (dans notre cas, cela
donne
Priority 12 BasePriority 8 PriorityDecrement 2), etc.
Voilà pour notre analyse de premier niveau qui vous aidera
dans pas mal de cas et quasiment systématiquement pour les problèmes de driver.
Pour aller plus en profondeur dans l’analyse de dump mais aussi le debuggage
d’application avec Windbg, je vous recommande l’aide et la lecture d’ouvrages
sur le sujet, comme indiqué en introduction.
Quatrième étape : corriger le problème
Une fois le fichier, cause de tous vos malheurs, identifié,
il reste à retrouver le driver dont il fait parti. Pour cela, je vous
recommande de faire comme suit :
1. rechercher le fichier sur le disque (en priant pour qu’il
n’y en ait qu’un)
2. regarder les propriétés de ce fichier, en faisant un
bouton droit sur le fichier puis aller dans l’onglet version
Les informations que vous y trouverez vous permettront de
trouver le fabriquant, des infos pour vous aider à identifier à quoi il sert.
Dans le cas où cette description serait vide, il vous reste encore la
possibilité de regarder dans quel répertoire est ce fichier et quelle sont ceux
qui l’entour. S’il est vraiment tout seul dans un répertoire banalisé ou perdu
au milieu du répertoire windows\system32, le dernier espoir est la recherche de
toutes les chaînes de caractères du fichier. En général, on y trouve des
informations sur les clés de registre, des messages d’erreur, etc.
Dans le cas d’un fichier appartenant à un driver, utilisez
le gestionnaire de périphérique pour retrouver exactement le driver en cause.
3. une fois le fichier et son environnement identifié, il ne
vous reste plus qu’à agir : en général cela passe par l’installation d’un
nouveau driver ou le passage d’u, bon patch.
Dans tous les cas, quand le problème est bien identifié et
que vous avez à votre disposition quelques bon dump, cela vous permet de
trouver des arguments pour obtenir le développement de nouvelles versions de
drivers ou de patchs.
Conclusion
J’espère vous avoir donné les clés nécessaires à vous lancer
dans ce type d’analyses. Elles vous permettront non seulement de faire le fier
à la machine à café mais surtout d’améliorer la stabilité de votre machine.
Vous avez également la possibilité de laisser Microsoft
faire une partie du boulot pour vous en vous connectant sur le site http://oca.microsoft.com et en soumettant
vos minidump de Windows 2000 ou Windows XP sur le site. Le truc sympa c’est
qu’ils sont analysés et parfois vous avez une réponse pertinente vous indiquant
un driver à mettre à jour. Si vous utilisez Windows XP, suite à un crash, une
boîte de dialogue s’ouvre et vous demande si vous souhaitez envoyer un rapport
à Microsoft. Faites-le, nous l’utilisons pour savoir d’où viennent les
problèmes et les corriger ou les faire corriger par les constructeurs de
hardware développant leurs drivers.
Bonne analyse…
|
|
 |
 Pour afficher ou poster un commentaire, cliquez sur ce lien : Forum-Microsoft
|
|
Tech-Ed 2002 : Analyser un Dump par Laurent Ellerbach
