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.

War es hilfreich?

Lösung

Dies ist, wie ich das Problem für einen Anwender mit einem Absturz angehen würde.

  1. Download und Debugging Tools für Windows unter http: // www .microsoft.com / WHDC / devtools / Debugging / default.mspx

  2. Nachdem die Tools installiert sind (sie am Ende zu C gehen: \ Programme \ Standard). Ein Kommandozeilenfenster starten

  3. Wechseln Sie in das Verzeichnis, das adplus (z "C: \ Programme \ Debugging Tools für Windows (x86)") enthält.

  4. 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ühren

diese 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

scroll top