Wie log .NET 2.0-Fehlerberichterstattung Meldungen im Ereignis beheben?
-
03-07-2019 - |
Frage
Ich arbeite an einem Open-Source-Produkt namens EVEMon in C # geschrieben, um die .NET 2.0-Plattform-Targeting, I habe einen Benutzer, der von einem fremden .NET Absturz leidet, dass wir nicht in der Lage gewesen, zu lösen.
Event Type: Error Event Source: .NET Runtime 2.0 Error Reporting Event Category: None Event ID: 5000 Date: 4/29/2009 Time: 10:58:10 PM User: N/A Computer: removed this Description: EventType clr20r3, P1 evemon.exe, P2 1.2.7.1301, P3 49ea37c8, P4 system.windows.forms, P5 2.0.0.0, P6 4889dee7, P7 6cd3, P8 18, P9 system.argumentexception, P10 NIL. Data: //hex representation of the above Description
Die Anwendung selbst mit aus stürzt einen Fehler anzeigt (trotz einer Fehlerbehandlung UI hat), wurde die obigen Meldungen aus dem Windows-Ereignisprotokoll kopiert. Der Endanwender hat neu installiert .NET und auf die neuesten Versionen aktualisiert. Die PDB-Dateien mit jeder Release-Version des Programms verteilt werden in Debuggen und Testen zu unterstützen, kann der Benutzer mit dem Problem in Frage hat die volle Ergänzung der PDB-Dateien für die korrekte Version von EVEMon.
Gibt es eine spezielle, bewährte Technik, um diese Art von Absturz zu analysieren und zu diagnostizieren? und wenn ja, welche Werkzeuge und Technologien zur Verfügung, bei der Fehlersuche helfen?
Besonderer Dank
würde Ich mag besonderen Dank an Steffen Opel und Highlights geben, die a href <= "https://stackoverflow.com/questions/814560/how-to-troubleshoot-net-2-0-error-reporting-messages -in-the-event-log / 1082254 # 1082254" > seine Antwort zwar nicht direkt die Frage zu beantworten ich fragte, adressiert das größere Problem mit meinem Code-Basis, dass die globale Fehlerbehandlung eine wichtige Komponente fehlt.
Lösung
Dies ist, wie ich das Problem für einen Anwender mit einem Absturz angehen würde.
-
Download und Debugging Tools für Windows unter http: // www .microsoft.com / WHDC / devtools / Debugging / default.mspx
-
Nachdem die Tools installiert sind (sie am Ende zu C gehen: \ Programme \ Standard). Ein Kommandozeilenfenster starten
-
Wechseln Sie in das Verzeichnis, das adplus (z "C: \ Programme \ Debugging Tools für Windows (x86)") enthält.
-
Führen Sie den Befehl follwing. Dadurch wird die Anwendung starten und adplus befestigen.
adplus -crash -o C:\debug\ -FullOnFirst -sc C:\path\to\your\app.exe
Nachdem das Crash-Dump erstellt
Wenn die Anwendung abstürzt WinDbg starten und die DMP-Datei laden, die in C erstellt: \ debug. (File -> Open Crash-Dump)
Ausführendiese Befehle den Stack-Trace, um zu sehen und hoffentlich das Problem finden.
SOS So laden Sie zum Debuggen von
- Pre .NET 4.0
.loadby sos mscorwks
- .NET 4.0
.loadby sos clr
, um die Stack-Trace sehen
!clrstack
Um einen nützlichen Stack-Trace finden Sie unter
!clrstack –p
stecken im Inneren eines object..perhaps sehen, was die Ausnahme verursacht
!do <address>
z Dies ist das Ergebnis aus einer Anwendung, die zufällig mit einer IO-Ausnahme bemängelte. WinDbg wies den Weg aus, auf die verwiesen wurde, die nicht korrekt war.
0:009> !do 017f2b7c
Name: System.String
MethodTable: 790fd8c4
EEClass: 790fd824
Size: 124(0x7c) bytes
(C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
String: \\server\path\not_here.txt
Fields:
MT Field Offset Type VT Attr Value Name
79102290 4000096 4 System.Int32 1 instance 54 m_arrayLength
79102290 4000097 8 System.Int32 1 instance 53 m_stringLength
790ff328 4000098 c System.Char 1 instance 5c m_firstChar
790fd8c4 4000099 10 System.String 0 shared static Empty
>> Domain:Value 00161df8:790d884c <<
7912dd40 400009a 14 System.Char[] 0 shared static WhitespaceChars
>> Domain:Value 00161df8:014113e8 <<
Andere Tipps
Spähen in den Quellcode (Stamm) zeigt an, dass nicht behandelte Ausnahmebehandlung in Bezug auf zu sein unvollständig scheint auf Windows Forms-Anwendungen:
Sie müssen behandeln beide Nicht-UI-Thread Ausnahmen und UI-Thread Ausnahmen:
-
Für die ehemalige benötigen Sie eine CLR nicht behandelte Exception-Handler über
AppDomain.CurrentDomain.UnhandledException
zu implementieren, die bereits vorhanden ist. -
Für letztere benötigen Sie einen Windows Forms nicht behandelte Exception-Handler über
Application.ThreadException
, implementieren, die zu fehlen scheint; Dies könnte in der Tat ergeben genau die Probleme, die Sie erleben. Für eine Implementierung Beispiel siehe MSDN-Dokumentation von Application.ThreadException Ereignis .
Bitte beachten Sie, dass gerade jetzt explizit Sie nicht behandelte Windows Forms Ausnahmen über Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException)
Fang unterdrücken, werden Sie dies ändern müssen, um UnhandledExceptionMode.CatchException
für Application.ThreadException
Routing zu Ihrem Handler zu ermöglichen, wie es richtig von Jehof bereits vorgeschlagen.
Was Betriebssystem (Windows XP, Windows Vista, etc.) muss der Benutzer verwenden?
Wenn Windows Vista versuchen zu deaktivieren „Problemberichte und -lösungen Feature“ (Systemsteuerung -> Problemberichte und -lösungen -> Einstellungen ändern -> Erweiterte Einstellungen -> Schalten Sie für meine Programme, Problemmeldung)
Oder versuchen Sie auf
Application.SetUnhandledExceptionMode( UnhandledExceptionMode.CatchException );
Dies wird immer Route Ausnahmen von dem Thread Handler.
Auf den Punkt gebracht: Es gibt eine nicht behandelte Ausnahme in der Anwendung.
Wenn Sie Zugriff auf die Maschine haben (über Fernzugriff, etc.), versuchen, Visual Studio Express Installation und die Anwendung starten. Sie sollten einen Dialog bieten die Möglichkeit, sehen die Anwendung mit einer neuen Instanz von Visual Studio zu debuggen.
Es kann auch sein, dass es etwas zu verhindern Windows Forms aus richtig initialisiert ist. Ich habe Forum-Beiträge gesehen, die darauf hinweisen, dass die Schrift gibt diese verursachen kann - dafür zu sorgen, dass die Benutzer haben die Schriftarten installiert, die die Anforderungen Ihrer Anwendung zuzüglich den üblichen Standardwerte wie MS SansSerif, Arial, Tahoma, Zeiten und ähnliches
.Und das Ausfallen ... versuchen, ein Huhn über den PC zu opfern. Arbeitet ein Zauber jedes Mal!
Wir haben Probleme mit Ausnahmen in Thread-Kodex haben. Wenn Sie einen neuen Thread laichen und vergessen eine Ausnahme im Thread Verfahren zu handhaben, die Anwendung nur „stoppt“ - keine Fehlermeldung, keine gar nichts, sondern nur einen Eintrag im Ereignisprotokoll. Nicht einmal dann UnhandledExceptionHandler
ausgelöst wird.
Vielleicht so etwas ist die Ursache?
... wenn Sie in der Lage sind, eine derartige Leiden Benutzer zu kontaktieren, hier ist ein
Idee: log Pre-Ausführungsstufen
Statt eine Verknüpfung zu Ihrer program.exe
zu machen, eine Verknüpfung machen program.bat
, das wird
echo "Pre-start" > stage.txt
start program.exe
Die erste Zeile des Program.cs
wird daher sein,
File.WriteAllLines("stage.txt", "Program execution started.");
In der Prozedur von AppDomain.UnhandledException
ersten Zeile wird
File.WriteAllLines("stage.txt", "Unhandled exception has been caught.");
Also, stellen Sie sicher, dass der Handler nicht Speicher oder Ressourcen zuteilt - Pre-ordnen sie auf Programme starten. Handler nur löst das Schreiben in das Protokoll.
Kommentare
Es ist sehr wahrscheinlich, dass die stage.txt
(durch den Benutzer gesendet) „Pre-start“ enthalten wird. Dies geschieht, wenn eine Ausnahme in 3rd-Party-DLL ausgelöst wird -. Noch bevor das Programm gestartet hat
In diesem Fall müssen Sie ein einfaches Prüfungsprogramm, das nicht die Assemblys verweisen, die Sie program.exe
tun, sondern sie Assembly.Load(...)
.
P. S.
stage.txt
irgendwo unter% APPDATA%, nicht in Program Files werden sollte platziert.
Ich fand einen interessanten Fall auf Server 2003 und andere nette Diskussion .
Sie sollten eine detailliertere Stack-Trace erhalten, indem die .pdb
Datei für das jeweilige Release an den Benutzer zu senden (Put neben dem .exe
werden) und mit ihnen den Absturz reproduzieren.
Sie sollten AppDomain.UnhandledException
im Code behandeln.
Es war ein