METHODE PRO
+ de 3413
lectures 
0- Intro
|
******************************************************************************* |
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).
--------------------------------------------------------------------------------------------------------------------------------------------------
2- 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
ou ICI. 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 symboles 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 services 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.
---------------------------------------------------------------------------------------
4- 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.
-------------------------------------------------------------------
5- 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…
----------------------------------------------------------------------
Veuillez penser à participer au
sondage une fois terminé. Merci
Copyright © 2008 serrano-n, All Rights
Reserved