Debuggen einer ausführbaren C # -Datei, die beim Start abstürzt

7

Ich versuche, ein C # -Programm remote zu debuggen. Die Verbindung mit dem Host ist kein Problem und ich kann alle Prozesse sehen, die auf diesem Computer ausgeführt werden, und kann eine Verbindung mit der msvsmon.exe herstellen.

Allerdings stürzt das Programm, das ich debuggen möchte, sofort beim Start ab und gibt mir keine Zeit, mich daran zu heften. Auch das Starten der Debug-ausführbaren Datei über einen Remote-Speicherort führt zu nichts. Wie kann ich vor dem Absturz einen Debugger anhängen?

    
wonea 09.11.2010, 11:31
quelle

3 Antworten

10

Der Absturz beim Start ist möglicherweise auf eine fehlende Abhängigkeit zurückzuführen. Führen Sie fuslogvw.exe aus, bevor Sie Ihre Anwendung starten, und prüfen Sie, ob eine der Bindungsoperationen fehlschlägt.

Wenn das nicht hilft, ist es in der Regel eine gute Praxis, eine Diagnoseprotokollierung durchzuführen. Sie können eine dedizierte Protokollierungsbibliothek verwenden, z. Log4net, oder zumindest sollten Sie die einfachste Form der Protokollierung über System.Diagnostics.Trace verwenden. Sie können die Trace-Nachrichten abhören, indem Sie entweder einen Trace-Listener in der app.config konfigurieren oder Tools von Drittanbietern wie einen Debugger oder DebugView von Sysinternals verwenden.

Wenn Sie tatsächlich einen Debugger anhängen möchten, können Sie einen Haltepunkt programmgesteuert einfügen:

%Vor%

Ich habe nicht überprüft, wie dies mit einem Remote-Debugger funktioniert, aber als letzte Möglichkeit können Sie Ihre Anwendung lange genug schlafen lassen, damit Sie einen Debugger anhängen können:

%Vor%     
Dirk Vollmar 09.11.2010, 11:36
quelle
13

Einer meiner Lieblingstricks zum Anhängen eines Debuggers beim Programmstart ist Image File Execution Options . Es ist eine Registry-Funktion, mit der Sie unter anderem einen Debugger an eine Anwendung anhängen können, bevor sie ausgeführt wird. Mit demselben Trick können Sie zum Beispiel Ihren Windows Task-Manager durch Prozess-Explorer oder Notepad.exe ersetzen. mit Notepad2 .

Sie können alles darüber hier lesen.

>

So richten Sie es ein:

  • Ausführen regedit.exe
  • Gehe zu HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
  • Erstellen Sie einen neuen Schlüssel mit dem Namen exe (Beispiel: yourprogram.exe)
  • Erstellen Sie einen neuen Zeichenfolgenwert unter Ihrer exe. Der Name des Zeichenfolgenwerts ist Debugger und der Wert ist vsjitdebugger.exe

Wenn Sie die ausführbare Datei ausführen, werden Sie in der Just-in-Time-Eingabeaufforderung aufgefordert, einen Debugger auszuwählen:

Wenn dieses Dialogfeld geöffnet ist, verbinden Sie es remote mit Ihrem Prozess und drücken Sie No im Dialogfeld.

Ich hoffe, das hilft.

    
Igal Tabachnik 10.11.2010 15:12
quelle
0

Nach langem Suchen wurde mir klar, dass WPF die Ursache für das Problem war. Rudsens Blog enthüllt die answer.

Im Anwendungsprotokoll wäre der folgende Fehler:

.NET Runtime 4.0 Fehlerbericht

Ereignistyp clr20r3, P1 eobfrontend.exe, P2 1.0.0.0, P3 4cd95cc7, P4 Präsentationsrahmen, P5 4.0.0.0, P6 4ba1f8db, P7 78ff, P8 0, P9 system.windows.markup.xamlparse, P10 NIL.

Realisiert als Rudsen bemerkte "dass der Fehler bedeutet, dass es einen Laufzeitfehler gab, der den Xaml-Code parsierte". Ich folge den Schritten "Open Debug & gt; Ausnahmen" und aktiviere das Kontrollkästchen im "geworfen" Spalte für "Common Language Runtime Exceptions". Damit beendet Visual Studio alle Ausnahmen. "

    
wonea 10.11.2010 14:57
quelle