Sébastien Bovo [Microsoft France] : Debogage

Debogage .NET 4.0

Sebastien Bovo — Mon, 30 Nov 2009 20:32:00 GMT

Visual Studio 2010 et le .NET Framework 4 sont disponible en Beta 2 depuis quelques semaines. Afin de vérifier un comportement qui m’a un peu surpris, je vais les utiliser pour le débogage.

Voici le contexte : Dans un précédent billet, je parlais du deployment retail="true" pour ASP.NET en faisant référence au billet de Scott Guthrie. Je pensais que retail=true était la solution pour s’affranchir du debug=true dans tous les Web.config du serveur. C’est seulement en parti vrai car le timeout des pages ASP.NET n’est pas modifié et reste démesuré si vous avez debug=true dans votre Web.config.

Voici la preuve…

Page d’exemple

J’utilise un page exemple qui ne se termine jamais. Dans la vrai vie, nous aurons une boucle infinie plus complexes ou un bloclage quelconque. Dans tous les cas, le débogage est identique. Mon but est d’obtenir le timeout des pages ASP.NET.

<%@ Page Language="C#" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

    protected void Page_Load(object sender, EventArgs e)
    {
        DateTime t1 = DateTime.Now;
        while (true)
        {
            DateTime t2 = DateTime.Now;
        }
    }
</script>

Clin d’œil à Visual Studio 2010 et l’utilisation du zoom (CTRL+mollette de la souris) :

Cette page doit être positionnée dans un site Web utilisant un pool d’application configuré avec le Framework 4.0.

Avant de lancer WinDbg, naviguons vers notre page de test.

Lancement de WinDbg, chargement des symboles et SOS

Veillez bien à lancer Windbg en tant qu’administrateur et attachez-vous au processus W3WP.EXE en cours d’exécution (F6) :

Chargement des symboles publics :

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

Chargement de SOS livré avec le .NET Framework 4.0 :

.load C:\Windows\Microsoft.NET\Framework\v4.0.21006\SOS

Affichage des objets

Maintenant, cherchons notre page en court d’exécution

!DumpHeap -type System.Web.HttpContext

!do 062d9d18

Comme il s’agit d’un objet de type TimeSpan, nous devons utiliser la méthode !DumpVC (Pour information, voici le pointeur MSDN vers SOS - http://msdn.microsoft.com/en-us/library/bb190764.aspx)

!DumpVC 532747bc 062d9dd0

La valeur du timeout donnée est un nombre de ticks CPU. Sachant qu’il y a 10000 ticks par millisecondes. Pour obtenir le temps en secondes, nous devons donc diviser la valeur par 10000 puis par 1000. Utilisons Windbg comme calculatrice :

?1100000000/10000/1000

Le timeout de la page ASPX est de 110 secondes.

Nous avons bien le comportement normal et celui par défaut décrit dans le fichier "Web.config.comments" :

Maintenant, regardons avec exactement la même démarche, ce que nous avons avec debug=true (dans Web.config) et retail=true (dans le Machine.config) :

Je vous passe toutes les copies d’écran, voici juste les deux dernières commandes :

Le timeout est de 30 000 000 secondes soit 347 jours. Effectivement, dans ce cas, nous avons tout le temps de déboguer nos pages… Et le retail=true n’a pas changé ce comportement.

La conclusion est : vérifiez que vous n’avez pas debug=true dans tous les Web.config en production même si vous avez retail=true.

Plutôt intéressant :-) Qu’en pensez-vous ?

Sebastien.

Debogage Silverlight avec WinDbg et SOS - C'est possible !

Sebastien Bovo — Fri, 30 Oct 2009 16:20:00 GMT

Tout comme les applications développées en .NET, qu'elles soient clientes (Windows Forms, WPF) ou serveurs (ASP.NET, Service Windows, WCF), les applications Silverlight ont aussi le droit d’être déboguées !

Comment analyser un crash ou une fuite mémoire de nos applications riche Internet ? "Tout simplement" (façon de parler) de la même manière que pour toutes les autres... avec WinDbg.

Cela veut donc dire que ce que nous avons vu sur le débogage .NET avec WinDbg et SOS est valable : C’est un luxe de pouvoir s’appuyer sur ses acquis !

Si vous n’êtes pas familier avec WinDbg et SOS, je vous invite à lire mes précédents articles :

Premiers pas avec WinDbg - http://blogs.msdn.com/sbovo/archive/2009/06/19/premierpasavecwindbg.aspx
Debogage .NET avec WinDbg et SOS - Threads - http://blogs.msdn.com/sbovo/archive/2009/07/23/debogage-netavecwindbgetsos.aspx
Debogage .NET avec WinDbg et SOS - Objects - http://blogs.msdn.com/sbovo/archive/2009/07/06/debogage-netavecwindbgetsos-objects.aspx
Debogage .NET avec WinDbg et SOS - Travaux Pratiques - http://blogs.msdn.com/sbovo/archive/2009/08/04/debogage-netavecwindbgetsos-travauxpratiques.aspx

Allez zou… Démonstration !

1. Exemple d’application

Prenons un exemple le plus simple possible. Le but est de pouvoir être capable de visualiser nos appels de fonctions et nos objets. Pour ce faire, j’ai créé un nouvelle application Silverlight et modifié le code associé à la page par défaut ("MainPage.xaml.cs") :

J’utilise une liste d’objets d’un type particulier "Elt" > Ce qui me permettra de les différencier dans WinDbg
Cette liste est rempli au démarrage et je marque un temps d’arrêt avec un message destiné à l’utilisateur > Ce qui me laissera le temps de lancer WinDbg et m’attacher au processus

Voici le code (mémorisez l’espace de nom)

namespace ExempleSL
{
    public partial class MainPage : UserControl
    {
        private List<Elt> listeElements = new List<Elt>();

        public MainPage()
        {
            for (int i = 0; i < 10; i++)
            {
                listeElements.Add(new Elt() { Name = "elt" + DateTime.Now.Millisecond, Donnees = i });
            }
            MessageBox.Show("Continuer ?");
            InitializeComponent();
        }

        public class Elt
        {
            public string Name { get; set; }
            public int Donnees { get; set; }
        }
    }
}

C’est parti : lancement de l’application avec CTRL+F5 dans Visual Studio.

Le message apparait : nous pouvons lancer le débogueur pour regarder ce que nous avons en mémoire.

2. S’attacher au processus avec WinDbg

Les applications Silverlight s’exécutent dans le navigateur. Il ne faut donc pas chercher à prendre un dump ou s’attacher à ExempleSL.exe mais plutôt à iexplore.exe.

Lançons WinDbg en tant qu’administrateur et attachons-nous au processus avec "FILE / Attach to process…" ou F6. Prenons iexplore.exe.

Ensuite, comme nous le faisons à l’accoutumé, 3 étapes :

Renseignement du serveur de symboles

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

Chargement des symboles

.reload

Chargement de l’extension SOS pour Silverlight

.load c:\Program Files (x86)\Microsoft Silverlight\3.0.40818.0\sos

Notez bien que nous avons une version sos.dll par version du Framework dans C:\windows\Microsoft.NET\Framework\vX et un une version sos.dll par version de Silverlight.

3. Deboguer

La liste des commandes disponibles de SOS est donnée par

!help

Pour savoir quel code est en cours d’exécution dans notre application, nous lançons une commande qui s’exécutera sur tous les threads du processus. Cette commande est "!ClrStack". Elle nous permet d’obtenir la pile d’appel d’un thread.

~*e !ClrStack

Beaucoup de threads ne sont pas en cours d’exécution de code Silverlight :

Mais le thread 5, l’est :

ESP EIP
02abd4f4 77cd9a94 [NDirectMethodFrameStandalone: 02abd4f4] MS.Internal.XcpImports.MessageBox_ShowCoreNative(IntPtr, System.String, System.String, UInt32, Int32 ByRef)
02abd510 03fd84f2 MS.Internal.XcpImports.MessageBox_ShowCore(System.String, System.String, UInt32)
02abd52c 03fd8449 System.Windows.MessageBox.ShowCore(System.String, System.String, System.Windows.MessageBoxButton)
02abd55c 03fd835c System.Windows.MessageBox.Show(System.String)
02abd56c 03f40376 ExempleSL.MainPage..ctor()
02abd5c8 03f401fe ExempleSL.App.Application_Startup(System.Object, System.Windows.StartupEventArgs)
02abd5e0 03fa69c9 System.Windows.CoreInvokeHandler.InvokeEventHandler(Int32, System.Delegate, System.Object, System.Object)
02abd6a0 03fa3b04 MS.Internal.JoltHelper.FireEvent(IntPtr, IntPtr, Int32, System.String)
02abd884 694917b0 [GCFrame: 02abd884]
02abd940 694917b0 [ContextTransitionFrame: 02abd940]
02abda38 694917b0 [UMThkCallFrame: 02abda38]

Nous voyons donc noir sur blanc, le "cheminement" d’exécution.

D’abord nous avons le démarrage de l’application avec "ExempleSL.App.Application_Startup"
Puis le constructeur de la clase MainPage ("ExempleSL.MainPage..ctor")
Et enfin, l’affichage de notre message : "System.Windows.MessageBox.Show"

Est-il possible de visualiser nos objets en mémoire ?

Oui, la méthode "!DumpHeap" nous donne tous les objets .NET en mémoire. Le paramètre "-type" nous permet de filtrer sur les objets dont le nom de la classe contient "ExempleSL".

!DumpHeap -stat -type ExempleSL

total 13 objects
Statistics:
      MT    Count    TotalSize Class Name
039d3dcc        1           24 System.Collections.Generic.List`1[[ExempleSL.MainPage+Elt, ExempleSL]]
039d3868        1           44 ExempleSL.App
039d3c24        1           84 ExempleSL.MainPage
039d3d6c       10          160 ExempleSL.MainPage+Elt

Nous avons bien

Notre liste
1 objet pour notre application
1 objet pour notre page
Les 10 éléments de la liste

cqfd :-)

"Deboguer ce dump" dans le menu contextuel de l’explorateur Windows

Sebastien Bovo — Thu, 14 May 2009 15:12:00 GMT

Voici un petit raccourci bien pratique lorsque vous avez à ouvrir des dumps avec WinDbg :

Windows Registry Editor Version 5.00

; Ajout de la fonctionnalité d’ouverture en double clic d’un dump par WinDbg dans le menu contextuel de l'explorateur Windows
; Cette fonctionnalité est ajouté pour les fichiers .DMP

[HKEY_CLASSES_ROOT\.dmp]
@="SB-DebugDumpFile"

[HKEY_CLASSES_ROOT\SB-DebugDumpFile]

[HKEY_CLASSES_ROOT\SB-DebugDumpFile\DefaultIcon]
@="c:\\debuggers\\windbg.exe"

[HKEY_CLASSES_ROOT\SB-DebugDumpFile\Shell]

[HKEY_CLASSES_ROOT\SB-DebugDumpFile\Shell\SB-DebugThisDump]
@="-> Deboguer ce dump"

[HKEY_CLASSES_ROOT\SB-DebugDumpFile\Shell\SB-DebugThisDump\Command]
@="\"C:\\debuggers\\windbg\" -z \"%1\""

A noter, que j’utilise le chemin "c:\debuggers\windbg.exe" ; N’oubliez pas de le changer si vous avez les outils de débogage dans un autre répertoire.

Maintenant, un double clic sur un dump suffit pour l’ouvrir dans WinDbg !

A bientôt,

Sebastien.

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

Sebastien Bovo — Wed, 13 May 2009 17:38:00 GMT

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".

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.

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

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

Données à récolter pour un travail de surveillance ou d'investigation sur un serveur Web

Sebastien Bovo — Wed, 26 Nov 2008 10:35:00 GMT

Afin de commencer un travail d’investigation sur le fonctionnement d’une application Web (erreurs, crashes, performance, fuites mémoire), les données les intéressantes à récupérer d’un serveur Web sont :

- Logs IIS

- Logs HTTPERR

- Journaux d’événements

- Logs perfmon si possible

- Dumps si necessaire

Voici plus de précisions :

Logs IIS

Les logs IIS sont les fichiers contenus dans « C:\windows\system32\logfiles\W3SVCxxxx ». xxxx représente le numéro du site Web.

Vous avez ensuite un ou plusieurs fichiers portant la date du jour

Référence pour les codes IIS :

Description of Microsoft Internet Information Services (IIS) 5.0 and 6.0 status codes - http://support.microsoft.com/kb/318380/en-us

Logs HTTPERR

Il s'agit des logs de la partie Kernel de Windows qui réceptionne les requêtes et envoie les réponses.

Pour analyser les messages d'erreurs contenus dans ces logs :

Error logging in HTTP API - http://support.microsoft.com/kb/820729/en-us

Les journaux d’évènements Application, Système et Sécurité

Les journaux donnent des informations pertinentes sur les redemarrages d'IIS/des pools d'applications, sur erreurs remontés par les pools d'applications, etc...

WWW Service Events (IIS 6.0) - http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ea584d51-16b5-4be7-9e70-7c7487ca4500.mspx?mfr=true
WWW Service Worker Process Events (IIS 6.0) - http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ea584d51-16b5-4be7-9e70-7c7487ca4500.mspx?mfr=true

Deux précisions sur les logs IIS :

- Pour apprécier le temps total de traitement des requêtes par le serveur Web, nous vous conseillons d’activer le champ « time-taken » des logs IIS6. Ce champs donne le temps total de traitement de chaque requête à partir du moment où le serveur reçoit la requête jusqu’au moment où il renvoie la réponse HTTP. Cela englobe le temps de traitement Web Service et/ou Base de données sous-jacent.

- Le Win32 Status peut être aussi très utile. Il est possible d’en connaitre la signification avec l’outil « Err.exe » : Microsoft Exchange Server Error Code Look-up - Err.exe

Procédures de prises de dumps pour un serveur Web

Sebastien Bovo — Tue, 25 Nov 2008 10:50:00 GMT

Voici une procédure simple pour effectuer une prise de dumps sur IIS.

Utilisation d’ADPLUS.VBS

L’outil de prise de dumps est "adplus". Il est fourni avec les outils de débogage Windows téléchargeables à l’adresse - http://www.microsoft.com/whdc/devtools/debugging/.

La démarche d’installation que je vous conseille est la suivante :

- Télécharger les outils de débogage

- Faire l’installation sur une machine quelconque

- Copier sur le serveur Web le répertoire qui a été installé par les outils de débogage (par exemple dans « C:\debuggers\ »)

Prise d’un dump automatiquement lors d’un crash

Ouvrir une session avec un compte administrateur sur le serveur Web (se connecter avec « /console » si vous utilisez Terminal Serveur)
En ligne de commande, naviguer vers le répertoire contenant les outils de débogage
Lancer la commande suivante : « cscript.exe adplus.vbs -iis -crash -quiet ». A partir de ce moment, un débogueur est branché sur les processus IIS et prend un dump si un crash apparait
Récupérer le répertoire nommée de la façon suivante « Crash_Mode__Date_01-11-2007__Time_18-31-1515 »

Si vous avez beaucoup de mini-dumps, vous pouvez utiliser « cscript.exe adplus.vbs -iis -crash –quiet -nodumponfirst » pour avoir seulement un dump de second chance.

Prise d’un dump au moment du lancement de la commande

Pour une prise d’un dump immédiatement, dans le cas ou vous vous apercevez d’un problème ponctuel (application ne répondant pas, ayant de très mauvaises performances) ou dans le cas d’une fuite mémoire, la commande est « cscript.exe adplus.vbs -iis -hang -quiet » :

Ouvrir une session avec un compte administrateur sur le serveur Web (se connecter avec « /console » si vous utilisez Terminal Serveur)
En ligne de commande, naviguer vers le répertoire contenant les outils de débogage
Lancer la commande suivante : « cscript.exe adplus.vbs -iis -hang -quiet ». Les dumps des processus IIS sont pris immédiatement
Récupérer le répertoire nommée de la façon suivante « Hang_Mode__Date_01-11-2007__Time_18-31-1515 »

L’analyse des dumps se fait avec l’outil WinDbg (fourni avec les outils de débogage Windows) par vous et/ou par le support Microsoft.

Comment mettre en place le débogage distant avec Visual Studio .NET

Sebastien Bovo — Fri, 23 Mar 2007 19:32:00 GMT

Je vous propose, par ces quelques lignes, de clarifier l'insaisissable et célèbre "débogage distant avec Visual Studio .NET".

Conditions préalable

Pour simplifier les explications,

Appelons clientA notre station de travail et serveurB le serveur distant
ClientA fonctionne avec Windows 2000, Windows XP ou Windows 2003
ServeurB fonctionne avec Windows 2000 ou Windows 2003
clientA et ServeurB sont dans le même domaine Windows

D'autre part,

IIS et Visual Studio .NET sont installés sur ClientA
IIS est installé sur ServeurB
Si ServeurB fonctionne avec Windows 2000, le .NET Framework 1.1 doit être téléchargé et installé
Le compte du domaine utilisé fait parti des groupes Administrateurs, VS Développeurs et Utilisateurs du Débogueur sur clientA et sur ServeurB

Composants distants

Afin de pouvoir déboguer un processus sur un serveur distant, ce dernier doit pouvoir recevoir les ordres de débogage et communiquer en retour avec la station de travail. Ce sont les composants distants qui participent à ce travail.

Pour les installer, je lance l'installation de Visual Studio .NET. Sur le tout premier écran, j'utilise le lien Installations des composants distants. S'affiche ensuite une fenêtre dans laquelle il suffit localiser puis de cliquer sur le bouton Tout installer

Configuration du pare-feu

Le point délicat est celui de la configuration du pare-feu si nous avons Windows XP SP2 et Windows 2003 SP1. En effet, pour le débogage, il importe de pouvoir utiliser certains ports comme TCP 135, mais aussi d'autoriser des composants comme Mdm.exe, Vs7Jit.exe ou Msvcmon.exe.

Afin d'effectuer cette configuration, la fiche technique 841177 nous fourni l'outil DebuggerFirewall.hta. Ce dernier est une simple page qui liste les paramétrages nécessaires et les applique en un clic.

L'utilisation de DebuggerFirewall.hta est indispensable sur ClientA et ServeurB si le pare-feu est activé.

Si vous avez la curiosité de découvrir le travail dont nous soulage cet outil ou si vous avez besoin de faire les manipulations manuellement, voici tous les détails >> 833977

Points à vérifier si cela ne fonctionne pas

L'application doit est un répertoire virtuel dans IIS. Ce dernier doit avoir au moins l'authentification Intégrée Windows
La création du projet ASP.NET et son débogage doit se faire en utilisant le nom de serveur et non pas son adresse IP
Le Web.config de l'application doit avoir debug="true"
Dans l'explorateur de solution de Visual Studio, en cliquant droit sur le projet, vérifiez que le débogage ASP.NET est autorisé
Lorsque vous naviguez avec Internet Explorer sur l'application ASP.NET, vous devez être dans la zone Intranet ou Sites de confiance (cette condition n'est pas rempli si vous utilisez le nom complet du serveur comme ServeurB.Domaine1.com). Dans ce cas, ajoutez le nom du serveur à la liste des sites de la zone Intranet