Quelles sont les possibilités d’analyse post mortem dans .NET (par exemple, après un crash d’un programme)?

Question

Supposons qu’il existe un programme C #, utilisé comme service Windows. Supposons que le service est devenu sauvage et consomme le processeur et la mémoire comme un fou. Il doit être redémarré très bientôt, car il s’agit d’un système de production. Je n'ai donc pas beaucoup de temps pour rassembler les informations d'exécution. Peut-être un coup d’œil sur le gestionnaire de tâches ... c’est tout.

Après cela, je n'ai plus que les fichiers journaux log4net et le journal des événements Windows pour l'analyse post mortem.

Supposons que j'ai découvert la raison du problème. Quelqu'un d'autre le résout et peut-être le programmeur ajoute-t-il une journalisation supplémentaire afin que je puisse trouver un problème similaire plus rapidement la prochaine fois. Néanmoins, je reste tributaire de la qualité des fichiers journaux et j’espère que la prochaine fois qu’un problème se reproduira dans les enregistrements.

Existe-t-il également d'autres méthodes d'analyse post mortem? Peut-être que quelque chose comme les vidages de threads (comme en Java), les vidages de mémoire ou quelque chose d'autre, pourrait aider à l'analyse post mortem? Peut-être qu'un outil du framework .NET intégré peut-il vous aider?

Je suis très intéressé par les expériences de projets réels et par la manière dont vous tenteriez de résoudre cette question de maintenance, qui, à mon avis, est très réelle pour la plupart des programmeurs.

Answer 1

Comme le dit Marc, WinDbg + SoS vous permettra de déboguer beaucoup de problèmes que vous ne pouvez pas résoudre dans Visual Studio. Il existe d'excellents tutoriels ce blog .

Pour les problèmes de mémoire, vous pouvez également consulter les compteurs de performances .NET dans Perfmon. Vous pouvez voir où se trouvent les objets (quelle génération) et combien de temps est passé en récupération de place. Cela devrait vous donner des informations utiles. Si vous voulez savoir pourquoi les objets ne sont pas collectés, WinDbg et SoS sont la solution. Pour vous guider tout au long d’une session simple, procédez comme suit:

1. Inspectez le segment de mémoire à l'aide de !dumpheap -stat, recherchez un grand nombre d'instances. Vous avez probablement une idée de ce que vous vous attendez à trouver sur le tas à tout moment, alors si quelque chose vous semble hors du commun, examinez-le.

2. Choisissez une instance aléatoire et effectuez une !gcroot adresse sur l’instance. Cela vous dira pourquoi l'objet n'est pas collecté.

3. répéter

Il est probable que les candidats à la conservation de contenus actifs plus longtemps qu'ils ne le devraient: événements, statistiques et la file d'attente du finaliseur, pour en nommer quelques-uns.

Vous pouvez également consulter ma réponse pour cette question pour voir plus de choses WinDbg.

Answer 2

Vous pouvez créer des vidages sur crash avec .NET et les regarder avec windbg / sos (et sosassist). Pas simple, mais ça marche. Mais assez hardcore. Recherches sur & Quot; + windbg + .NET & Quot; devrait se révéler intéressant.

Autre que cela - des compteurs de ressources? les fichiers journaux? Beaucoup de choses que vous pouvez regarder et qui peuvent être activées assez facilement.

Answer 3

Malheureusement, j’ai dû faire pas mal de choses - le meilleur outil que j’ai rencontré est cordbg, qui est fourni avec le kit de développement (vous aurez besoin de la version correcte pour votre version .net). http://msdn.microsoft.com/en-us/library/a6zb7c8d. aspx pour plus de détails.

Attachez le processus en cours dans cordbg (a < [pid] >), attachez-le à chaque fil d'exécution en cours (t < [tid] >) puis dump la pile pour chaque thread (w).

L'automatisation de cette tâche avec un petit script vb, puis le basculement dans un fichier vous permettra d'exécuter cet outil plusieurs fois, en capturant la sortie dans un fichier. La comparaison de toutes les piles de threads vous donnera une très bonne idée de l'endroit où votre application passe son temps.

La bonne chose à propos de cette approche, en particulier avec l’automatisation des dumps, est que vous pouvez très rapidement saisir toutes les informations et faire redémarrer votre processus dans les meilleurs délais.

Answer 4

Tess Ferrandez ' série d'entrées de blog sur le sujet.

EDIT: lien mis à jour

Answer 5

Si le processus est toujours actif, vous pouvez exécuter l'explorateur de pile géré contre pour avoir un aperçu rapide de ce qu’il fait. Vous pouvez l'exécuter sans installation explicite.

En dehors de cela, un vidage complet + windbg + SOS vous donne le plus d'informations, mais y parvenir n'est pas anodin.