Plan d‘action pour la capture des informations lors d’un problème de production IIS


Je fais suite à mon précédent billet sur l’introduction sur le débogage en production afin de vous donner plus de précisions sur la collecte d’informations lors de l’apparition d’un problème en production.

 

Dans tous les cas se présentant à vous, je vous conseille de récupérer des serveurs Web les logs IIS, les logs HTTPErr et vos logs applicatifs. Vous trouverez les explications dans le billet Données à récolter pour un travail de surveillance ou d'investigation sur un serveur Web. Ces logs nous permettent de vérifier la charge utilisateur, les temps de réponses, les erreurs HTTP : ce sont des informations précieuses à relier avec le comportement observé de l’application. Aussi, si vous avez la possibilité de prendre un log Perfmon, cela constitue un apport d’informations supplémentaires.

 

D’un point de vue système, je résumerais les problématiques de production en deux comportements distincts :

  • Hang =  Etat de blocage "deadlock" (avec ou sans 100% CPU) ou d’attente "hang" du processus
  • Crash = Arrêt "crash" du processus

La prise de dumps peut se faire par le script Adplus. Voici comment faire : Procédures de prises de dumps pour un serveur Web

D’une manière générale, vous pouvez utiliser Adplus pour les prises de dumps/logs pour tous les processus et pas pour IIS seulement. Les paramètres les plus utiles sont :

-p –> Spécifie le PID du processus
-pn –> Donne le nom du processus (plutôt que son PID)
-o –> Renseigne le répertoire de sortie pour la création du dumps

Ainsi, pour une prise de dumps de plusieurs processus et la création des dumps dans un répertoire particulier, la commande ressemble à

cscript.exe adplus.vbs -pn w3wp.exe -pn inetinfo.exe -crash -o c:\temp -quiet

Deux autres paramètres sont utiles :

-NoDumpOnFirst –> Permet de ne pas surcharger le débogueur (et donc le serveur) qui prend un mini dump pour chaque exception de première chance. Logue toutes les exceptions levées
-NoDumpOnSecond –> Aucune prise de dump mais seulement le remplissage d’un log permettant de visualiser toutes les exceptions levées

Pour vous donner plus de précisions, en deux mots, il existe deux types d'exceptions : première chance et seconde chance.

  • Une exception de première chance peut être interceptée par votre application par un try/catch ou un gestionnaire d’exceptions global
  • Si cette exception n’est pas gérée, elle est à nouveau levée mais comme une exception de seconde chance. Dans ce cas, seul un débogueur peut l’intercepter et si aucun débogueur n’est attaché, l’application se ferme (autrement dit : le processus crashe).

Par exemple, pour une prise d’un dump lors du crash de l’application "WpfApplication1.exe", vous pouvez utiliser "cscript.exe adplus.vbs -crash -pn WpfApplication1.exe -o c:\temp -quiet".

Adplus.vbs

Cette commande a pour effet de brancher le débogueur "cdb.exe" au processus WpfApplication1.exe. Le debogueur logue toutes les exceptions dans un fichier pendant l’exécution du processus et si une exception de seconde chance est levée (provoquant l’arrêt du processus), un dump est pris.

cdb.exe

Le répertoire de sortie contient les fichiers suivants :

  • Process_List.txt - Liste des processus s’éxécutant sur la machine au moment du lancement de la commande
  • un ou plusieurs fichiers du type PID-2852__WPFAPPLICATION1.EXE__Date_05-13-2009__Time_15-46-0303.log - Log des exceptions levées par l’application
  • un ou plusieurs fichiers du type PID-2852__WPFAPPLICATION1.EXE__2nd_chance_NET_CLR__full_0a70_2009-05-13_15-46-10-421_0b24.dmp - Dump du processus

RepertoireSortie

A noter que le répertoire et les fichiers contiennent la date et l’heure exacte de la prise de dumps. Dans l’exemple précédent, il s’agit du 2009-05-13 pour le 13 mai et 15-46-10 pour 15h46m.

 

Nous avons donc maintenant toutes les données nécessaires (en particulier les dumps) pour déboguer à tête reposée. Ouvrons le dump avec Windbg 🙂

Sebastien.

>>> Suite : Premiers pas avec WinDbg

Skip to main content