Pour faciliter la prise en main de cet outil légendaire et pour que vous puissiez tester vous même, je suis parti avec le Starter Kit "BlogEngine” (http://www.asp.net/community/projects/) ; Vous pourrez ainsi prendre les dumps, les ouvrir et utiliser WinDbg en suivant les étapes ci-dessous.

J’ai donc copié les sources du Starter Kit dans le répertoire "C:\inetpub\wwwroot" : 

Ensuite, dans la console IIS, j’ai créé une application pour ce répertoire en choisissant le pool d’application "Classic .NET AppPool" :

C’est bon, l’application tourne, nous pouvons passer aux choses sérieuses…

 

Nous retrouvons le processus w3wp.exe avec le gestionnaire de taches, "process explorer" ou la commande suivante :

tasklist /FI "IMAGENAME eq w3wp.exe"

La prise de dumps peut se faire facilement avec adplus. Voici toutes les informations pour ce faire - Billet précédent : Plan d‘action pour la capture des informations lors d’un problème de production IIS

Pour nos tests aujourd’hui, je fais un simple clic droit sur processus dans le gestionnaire de taches puis "Create Dump File"

Ouvrons le dump par un double-clic ou en lançant WinDbg puis un glisser/déplacer du fichier .DMP dans l’interface de WinDbg… Un mot : Magnifique !!

 

Informations disponibles

 

Nous avons entre les mains une photographie de la mémoire utilisée par le processus. Au premier coup d’oeil, nous avons les informations suivantes

• La version exacte de Windows : Windows 7, build 7100 en 64bits
• Le jour et l’heure de la prise de dump : jeudi 18 juin à 14h10
• Le système d’exploitation tourne depuis 2 jours et 23 heures (System Uptime)
• Le processus est démarré depuis 13min et 9 secondes

Symboles

L’une des premières actions à faire est de paramétrer le serveur de symboles. En deux mots : Les symboles sont les fichiers .PDB donnant la correspondance entre les adresses mémoires et les noms des fonctions d’une dll ou d’un exécutable. WinDbg peut les utiliser pour nous afficher les piles d’appels avec les noms des fonctions plutôt que des adresses mémoire brutes : Appréciable est un adjectif faible pour décrire cet avantage :-)

Dans la zone de texte, en bas de l’interface, il vous suffit d’entrer

.sympath SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

pour spécifier le serveur public de symboles Microsoft : http://msdl.microsoft.com/symbols/. Dans l’exemple ci-dessus, je donne le crépertoire "c:\symbols" comme emplacement pour une copie locale des ces fichiers de symboles. WinDbg va donc pouvoir télécharger et stocker ces fichiers pour une utilisation déconnectée.

.reload

      Permet de charger les symboles et de les rapatrier en local s’il ne sont pas présents.

Modules

Sans commencer maintenant un débogage poussé, nous pouvons facilement connaitre quelle sont toutes les dlls chargées par le processus et obtenir des informations très précises sur chacune d’elles comme la date de build, le numéro de version, le chemin de la dll, etc…

L’affichage de toutes les dlls se fait par

lm

Nous obtenons les informations sur une dll avec

lmvm <<NomModule>>

 

 

Ce n’est que le début. Nous continuons dans le prochain billet.

Sebastien.

>>> Suite : Debogage .NET avec WinDbg et SOS - Threads