Debogage .NET 4.0


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

<script runat="server">

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

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
    </div>
    </form>
</body>
</html>

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

VS2010

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

WhileTrueSite4

ASP.NET V4.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) :WinDbg

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

DumpHeapHttpContext

!do 062d9d18

HttContext

 

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

Timeout

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

WinDbgCommeCalculatrice

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

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) :

debugtrue

retailtrue

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

TimeoutPourHttpContext

TimeoutDebug

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.

Comments (0)

Skip to main content