Debogage .NET avec WinDbg et SOS - Threads

Le débogage .NET diffère du débogage natif dans la mesure ou les objets et les piles d’appels qui nous intéressent ne sont pas visibles/exploitables sans utiliser une extension WinDbg nommée SOS.

Chargement de l’extension

Pour charger SOS dans WinDbg, la syntaxe est la suivante :

Vous pouvez vérifier la liste des extensions chargées avec

Pour information, le déchargement se fait avec

Démarrage

Permet d'obtenir lu numéro de version exact de la CLR chargée dans le processus.

La liste des commandes disponibles de l’extension s’obtient par

Vous trouverez l’aide complète en ligne sur MSDN : SOS Debugging Extension (SOS.dll) - https://msdn.microsoft.com/en-us/library/bb190764.aspx

Afin de visualiser un semblant d’activité, j’utilise TinyGet (un peu brusquement :-)) avec le lancement des deux commandes suivantes (2x50 utilisateurs simultanés effectuant 100 requêtes, les unes à la suite des autres)

et

Pendant l’exécution, après avoir lancé WinDbg en tant qu’administrateur, je m’attache au processus W3WP.EXE avec le menu FILE/Attach to process…

Ensuite comme d’habitude :

--

Voyons voir ce que nous avons et ce que nous pouvons obtenir avec WinDbg et SOS. Les questions que l’on peut se poser sont par exemple :

• Combien de threads exécutent des pages ASPX ?
• Quelles sont les pages exécutées ?
• Où en est leur traitement ?

Piles d’appels ou "call stacks"

Vous remarquerez le nombre en bas à droite de la fenêtre de Windbg : il s’agit du numéro du thread sur lequel nous somme positionné

Pour visualiser la pile d’appel de ce thread, la commande est

Loin d’être intuitif n’est pas ? En fait, c’est normal puisque nous visualisons les informations natives de la pile d’appels. Pour obtenir la pile d’appels managée, nous utilisons

Pour information, le changement de thread se fait avec

Où XX est le numéro du thread.

Comme raccourci, pour exécuter une commande sur tous les threads, nous pouvons utiliser

"e" permet d’exécuter une commande (contenu dans un extension - c'est le cas pour SOS)

Donc, si l’on reprend la pile d’appels du thread 20,
capture ci-dessus
System.Web.UI.HtmlTextWriter.WriteUTF8ResourceString(IntPtr, Int32, Int32, Boolean)
ASP.search_aspx.__RenderContent1(System.Web.UI.HtmlTextWriter, System.Web.UI.Control)
System.Web.UI.Control.RenderChildrenInternal(System.Web.UI.HtmlTextWriter, ... ASP.themes_standard_site_master.__Render__control5(System.Web.UI.HtmlTextWriter, ...
System.Web.UI.Control.RenderChildrenInternal(System.Web.UI.HtmlTextWriter, ...
System.Web.UI.HtmlControls.HtmlForm.RenderChildren(System.Web.UI.HtmlTextWriter)
System.Web.UI.HtmlControls.HtmlForm.Render(System.Web.UI.HtmlTextWriter)
System.Web.UI.HtmlControls.HtmlForm.RenderControl(System.Web.UI.HtmlTextWriter)
ASP.themes_standard_site_master.__Render__control1(System.Web.UI.HtmlTextWriter, ...
System.Web.UI.Control.RenderChildrenInternal(System.Web.UI.HtmlTextWriter, ...
System.Web.UI.Control.RenderChildrenInternal(System.Web.UI.HtmlTextWriter, ...
System.Web.UI.Page.Render(System.Web.UI.HtmlTextWriter)
BlogEngine.Core.Web.Controls.BlogBasePage.Render(System.Web.UI.HtmlTextWriter)
System.Web.UI.Page.ProcessRequestMain(Boolean, Boolean)
System.Web.UI.Page.ProcessRequest(Boolean, Boolean)
System.Web.UI.Page.ProcessRequest()
System.Web.UI.Page.ProcessRequest(System.Web.HttpContext)
ASP.search_aspx.ProcessRequest(System.Web.HttpContext)
System.Web.HttpApplication+CallHandlerExecutionStep...
System.Web.HttpApplication.ExecuteStep(IExecutionStep, Boolean ByRef)
System.Web.HttpApplication+ApplicationStepManager.ResumeSteps(System.Exception)
System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest ...
System.Web.HttpRuntime.ProcessRequestInternal(System.Web.HttpWorkerRequest)
System.Web.HttpRuntime.ProcessRequestNoDemand(System.Web.HttpWorkerRequest)
System.Web.Hosting.ISAPIRuntime.ProcessRequest(IntPtr, Int32)

Nous avons le nom de la page éxécutée : "search.aspx”. Elle est donnée par

Comme j’ai le code source sous la main, c’est plus facile ensuite de confirmer :-) :

La page maitre est "site.master" correspondant au thème "Standard" :

Vérification :-) :

Si l’on décortique la pile d’appels, nous obtenons un peu plus en détails. Nous avons l’enchainement des toutes les fonctions appelées. A noter que la lecture se fait de bas en haut (du plus ancien appel au plus récent).

La pile d’appels nous apprend que l’exécution de la page "search.aspx" a demandé le chargement de la classe "BlogEngine.Core.Web.Controls.BlogBasePage" et l'exécution de sa méthode "Render" : Nous devons être dans le cas d’un classe de base héritée.

puis

Nous avons ensuite, la demande de chargement de la page maitre et des contrôles contenus :

Enfin, au moment du débogage, nous étions toujours en dans la phase de génération la page Web :

C’est pas mal pour un début non ? La suite au prochain épisode.

A bientôt, Sebastien.

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