Wie Debuggen von zufälligen Abstürzen?

Question

Wir haben eine dotnet 2.0 Desktop Winforms App und es scheint zufällig zu stürzen. keine Stack-Trace, Vent Log oder irgendetwas. es verschwindet nur.

Es gibt einige Theorien:

1. Maschine einfach aus Ressourcen läuft. Einige Leute haben gesagt, dass Sie immer eine Fenster-Handle-Ausnahme oder eine GDI-Ausnahme erhalten werden, aber andere sagen, dass es einfach zu Abstürzen führen kann.

2. Wir verwenden Wrapper um nicht verwalteten Code für 2 Module. Ausnahmen in einem dieser Module können dieses Verhalten verursachen.

wieder, das ist ich irgendwelche Vorschläge waren, wie man besser oder etwas debuggen, wenn es sehen, nicht reproduzierbar, so wollte ich kann auf die Maschine setzen zu „fangen“ der Absturz, bevor sie uns helfen zu verstehen, geschieht was geht weiter.

Answer 1

Am besten kaufen Sie John Robbins Buch "Debugging Microsoft .NET 2.0 Applications". Ihre Frage kann viel tiefer gehen, als wir hier tippen können.

Answer 2

Sie könnten Process Monitor von SysInternals (jetzt ein Teil von Microsoft) verwendet, um genau das zu filtern, was Sie überwachen möchten. Dies würde Ihnen einen guten Startpunkt geben. Beginnen Sie einfach mit einem engen Fokus oder stellen Sie sicher, dass Sie genügend Platz für die Protokolldatei haben.

Answer 3

Haben Sie einen try/catch-Block um die Zeile 'Application.Run', der den GUI-Thread startet? Wenn nicht, fügen Sie eine hinzu und melden Sie sich für alle Ausnahmen an, die dort ausgegeben werden.

Sie können auch das Application.ThreadException-Ereignis aufrufen und protokollieren, falls Sie weitere Hinweise erhalten.

Answer 4

sollten Sie einen globalen Exception-Handler verwenden:
http://msdn.microsoft.com/en-us/library/system.windows.forms.application.threadexception.aspx

Answer 5

ich mit Boydski zustimmen. Aber ich biete diesen Vorschlag auch an. Sehen Sie sich die Threads genau an, wenn Sie Multi-Threading durchführen. Ich hatte einmal einen Fehler wie diesen, der eine lange Zeit brauchte, um es herauszufinden und endete damit, dass John Robbins am Telefon dabei half. Es stellte sich heraus, dass es sich um eine fehlerhafte Ausnahmebehandlung mit Threads handelte.

Answer 6

Klingt für mich wie Sie müssen sich zuerst anmelden - vielleicht können Sie mit PostSharp einen Logger an Ihre Methoden (see Log4PostSharp) anhängen. Dies wird Sie sicherlich verlangsamen und Tonnen von Nachrichten produzieren. Aber Sie sollten in der Lage sein, den problematischen Code einzugrenzen ... Fügen Sie dort weitere Protokolle hinzu - entfernen Sie andere. Vielleicht können Sie diese Teile später testen. Wenn die verdächtigen Teile klein genug sind, können Sie sogar eine Code-Überprüfung durchführen.
Ich weiß, Ihre Frage war über Debugging - aber das könnte auch ein Ansatz sein.

Answer 7

Ich meine Vergangenheit Ich habe diese Art von Verhalten in erster Linie in Bezug auf COM-Objekte nicht freigegeben und/oder Threading-Probleme. Sehen Sie sich die Vorschläge an, die Sie bereits erhalten haben, aber ich würde auch vorschlagen, zu prüfen, ob Sie die nicht verwalteten Objekte ordnungsgemäß freigeben, damit sie keinen Speicherverlust verursachen.

Answer 8

Führen Sie Ihre App mit pdb-Dateien aus, und hängen Sie WinDbg an, make run.
Whe Crash auftreten WinDbg Stop App.
Führen Sie diesen Befehl aus, um die Dump-Datei zu generieren:

.dump/ma c: \ myapp.
dmp

Ein Hilfsmittel der Analyse ist ADPlus

Oder diese versuchen:

Capturing user dumps using Performance alert
How to use ADPlus to troubleshoot "hangs" and "crashes"
Debugging on the Windows Platform