Déboguer une image mémoire managée avec les analyseurs de diagnostic .NET
Ce didacticiel présente les procédures suivantes :
- Ouverture d’un vidage de mémoire
- Sélectionner et exécuter des analyseurs sur le vidage
- Passer en revue les résultats des analyseurs
- Navigation vers le code problématique
Dans l’exemple décrit dans cet article, le problème est que votre application ne répond pas aux demandes en temps voulu.
Ouverture d’un vidage de mémoire dans Visual Studio
Ouvrez le vidage de mémoire dans Visual Studio à l’aide de la commande de menu Fichier > Ouvrir > Fichier, puis sélectionnez votre vidage de mémoire.
Notez sur la page Résumé du vidage mémoire une nouvelle Action appelée Exécuter l’analyse des diagnostics.
Sélectionnez cette action pour démarrer le débogueur et ouvrir la nouvelle page Analyse de diagnostic avec une liste d’options d’analyseur disponibles organisées par le symptôme sous-jacent.
Sélectionner et exécuter des analyseurs sur le vidage
Pour examiner ces symptômes, les meilleures options sont disponibles sous Réactivité du processus, car elle correspond le mieux au problème dans cet exemple.
Cliquez sur le bouton Analyser pour démarrer le processus d’investigation
L’analyseur présentera les résultats en fonction de la combinaison d’informations de processus et de données CLR capturées dans le vidage de mémoire.
Passer en revue les résultats des analyseurs
Dans cet exemple, l’analyseur a trouvé deux erreurs. Sélectionnez le résultat de l’analyseur pour afficher le Résumé de l’analyse et la Correction suggérée.
Le Résumé de l’analyse a déclaré que le « pool de threads CLR connaît une privation ». Ces informations suggèrent que le CLR a actuellement utilisé tous les threads de pool de threads disponibles, ce qui signifie que votre service ne peut pas répondre aux nouvelles demandes tant qu’un thread n’est pas libéré.
Notes
La Correction dans ce cas est « Ne pas attendre de manière synchrone sur les moniteurs, les événements, la tâche ou tout autre objet susceptible de bloquer le thread. Vérifiez si vous pouvez mettre à jour la méthode pour qu’elle soit asynchrone. ».
Navigation vers le code problématique
L’étape suivante consiste à trouver ce code problématique.
En cliquant sur le lien Afficher la pile des appels, Visual Studio bascule immédiatement vers les threads qui présentent ce comportement.
La fenêtre Pile des appels affiche des méthodes qui peuvent potentiellement faire la distinction entre le code (SyncOverAsyncExmple.) et le code Framework (System.).
Chaque trame de pile d’appels correspond à une méthode, et en double-cliquant sur les trames de pile, Visual Studio accède au code qui a conduit directement à ce scénario sur ce thread.
Dans cet exemple, il n’existe aucun symbole ou code. Toutefois, sur la page Symboles non chargés, vous pouvez sélectionner l’option Décompiler le source code.
Dans la source décompilée ci-dessous, il est évident qu’une tâche asynchrone (ConsumeThreadPoolThread) appelle une fonction de blocage synchrone.
Notes
La méthode « DoSomething() » qui contient une méthode WaitHandle.WaitOne, qui bloque le thread de pool de threads actuel jusqu’à ce qu’il reçoive un signal.
Pour améliorer la réactivité des applications, il est important de supprimer le code synchrone bloquant de tous les contextes asynchrones.
