Welche Möglichkeiten gibt es für die Post-Mortem-Analyse in .NET (z.B. nach einem Programmabsturz)?

Question

Nehmen wir an, es gibt ein C#-Programm, das als Windows-Dienst verwendet wird. Nehmen wir an, dass der Dienst verrückt geworden ist und CPU und Speicher wie verrückt verbraucht. Er muss sehr bald neu gestartet werden, da es sich um ein Produktionssystem handelt. Ich habe also nicht viel Zeit, um Laufzeitinformationen zu sammeln. Vielleicht ein kurzer Blick in den Task-Manager ... das ist alles.

Danach bleiben mir nur noch die log4net-Protokolldateien und das Windows-Ereignisprotokoll für die Post-Mortem-Analyse.

Angenommen, ich habe den Grund für das Problem herausgefunden. Jemand anderes behebt es, und vielleicht fügt der Programmierer zusätzliche Protokollierung hinzu, so dass ich ein ähnliches Problem beim nächsten Mal schneller finden kann. Trotzdem: Ich verlasse mich immer noch auf die Qualität der Protokolldateien und hoffe, dass das nächste Mal ein Problem irgendwie in den Protokollen auftaucht.

Gibt es auch andere Möglichkeiten der Post-Mortem-Analyse? Vielleicht so etwas wie Thread-Dumps (wie in Java), Speicher-Dumps oder etwas anderes, das bei der Post-Mortem-Analyse helfen kann? Vielleicht kann ein eingebautes .NET-Framework-Tool helfen?

Ich bin sehr an realen Projekterfahrungen interessiert und daran, wie Sie versuchen würden, diese Wartungsfrage zu lösen, die meiner Meinung nach für die meisten Programmierer sehr real ist.

Answer 1

Sie können mit .NET Crash-Dumps erstellen und diese mit windbg / sos (und sosassist) betrachten. Nicht einfach, aber es funktioniert. Aber ziemlich kompliziert. Eine Suche nach "+windbg +.NET" sollte sich als interessant erweisen.

Ansonsten - Ressourcenzähler? Protokolldateien? Es gibt eine Menge Dinge, die Sie sich ansehen könnten und die relativ einfach aktiviert werden können.

Answer 2

Wie Marc sagt, kann man mit WinDbg + SoS eine Menge Probleme debuggen, die man in Visual Studio nicht wirklich lösen kann. Es gibt einige ausgezeichnete Tutorials dieser Blog .

Bei Speicherproblemen können Sie auch einen Blick auf die .NET-Leistungszähler in Perfmon werfen. Sie können sich ansehen, wo sich Objekte befinden (welche Generation) und wie viel Zeit in der Garbage Collection verbracht wird. Das sollte Ihnen einige nützliche Informationen liefern. Wenn Sie wissen wollen, warum Objekte nicht gesammelt werden, sind WinDbg und SoS der richtige Weg. Die folgenden Schritte führen Sie durch eine einfache Sitzung:

1. Prüfen Sie den Heap mit !dumpheap -stat suchen Sie nach einer großen Anzahl von Instanzen. Sie haben wahrscheinlich eine Vorstellung davon, was Sie zu einem bestimmten Zeitpunkt auf dem Heap zu finden erwarten würden.

2. Wähle eine beliebige Instanz und führe eine !gcroot auf die Adresse der Instanz. So erfahren Sie, warum das Objekt nicht abgeholt wird.

3. Wiederholen Sie

Wahrscheinliche Kandidaten, die Dinge länger am Leben halten, als sie sollten, sind: Ereignisse, Statik und die Finalizer-Warteschlange, um nur einige zu nennen.

Vielleicht möchten Sie auch einen Blick auf meine Antwort für diese Frage um weitere WinDbg-Sachen zu sehen.

Answer 3

Eine hervorragende Quelle für die Post-Mortem-Analyse mit WinDbg und SOS ist Tess Ferrandez' Serie von Blogeinträgen zu diesem Thema.

EDIT: Link aktualisiert

Answer 4

Leider habe ich eine ganze Menge davon machen müssen - das beste Tool, auf das ich gestoßen bin, ist cordbg, das mit dem sdk geliefert wird (Sie benötigen die richtige Version für Ihre .net-Version). http://msdn.microsoft.com/en-us/library/a6zb7c8d.aspx für Einzelheiten.

Verbinden Sie sich mit dem laufenden Prozess in cordbg (a <[pid]>), verbinden Sie sich mit jedem laufenden Thread ( t <[tid]>) und geben Sie dann den Stack für jeden Thread aus ( w ).

Wenn Sie diese Aufgabe mit einem kleinen vb-Skript automatisieren und dann in eine Datei ausgeben, können Sie dieses Tool mehrmals ausführen und die Ausgabe in einer Datei speichern. Durch den Vergleich aller Thread-Stapel erhalten Sie eine sehr gute Vorstellung davon, wo Ihre Anwendung ihre Zeit verbringt.

Das Schöne an diesem Ansatz, insbesondere bei der Automatisierung der Dumps, ist, dass Sie sehr schnell alle Informationen erfassen und Ihren Prozess in kürzester Zeit wieder in Gang bringen können.

Answer 5

Wenn der Prozess noch aktiv ist, können Sie das Programm Verwalteter Stack Explorer um einen schnellen Überblick über das zu bekommen, was es tut. Sie können dies auch ohne eine explizite Installation durchführen.

Ansonsten liefert ein vollständiger Dump + windbg + SOS die meisten Informationen, aber es ist nicht trivial, diese zu bekommen.