Bienvenue sur le Laboratoire SUPINFO des technologies Microsoft !
Nous sommes étudiants et travaillons sur des centaines de projets sur les technologies Microsoft.
Nous préparons la migration de ce portail vers les technologies SharePoint 2013.
L'équipe du Laboratoire Microsoft


 


Tous les Articles du Laboratoire Microsoft

Tech-Ed 2002 : Analyser un Dump par Laurent Ellerbach
Accueil > Articles > Développement
Auteurs 
Laurent ELLERBACH



 Tous les articles de cet auteur

4,7/5

Très Bien


378196
144/688

*******************************************************************************
*                                                                             *
*                        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…




En Savoir Plus 
Evaluez cet article 


Pour afficher ou poster un commentaire, cliquez sur ce lien : Forum-Microsoft



Retrouvez ci-dessous les autres sections du Laboratoire Microsoft