Die Analyse von crash-dump in windbg

Ich bin mit third-party-closed-source-API, die eine exception wirft, die besagt, dass "alle named pipes beschäftigt sind".

Ich würde gerne Debuggen, dieses weiter (anstatt einfach Durchlaufen), so kann ich eigentlich erfahren, was geschieht, unter der Decke.

Habe ich ein dump der Prozess mit WinDbg. Welche Befehle soll ich jetzt verwenden, um zu analysieren, ist diese Müllkippe?

Dank

Ist es gelungen oder native? Können Sie werfen ein paar mehr details?

InformationsquelleAutor csharpdev | 2009-10-30

  1. 13

    Könnten Sie tun beginnen Sie wie folgt vor, um einen überblick über die Ausnahme:

    !analyze -v

    Konnte man nun laden die Ausnahme-Kontext-record:

    .ecxr

    ... Und jetzt nehmen Sie nur einen Blick auf den stack, Register, threads,...

    kb     ;will show you the stack trace of the crash.
dv     ;local variables

    Abhängig von der Hinweise, die Sie erhalten, sollten Sie eine andere Richtung. Wenn Sie wollen eine schnelle Referenz zu WinDbg ich würd dir empfehlen dieser link.

    Ich hoffe, Sie finden einige dieser Befehle und info nützlich.

    InformationsquelleAutor David A.

  2. 4

    In post-mortem-debugging mit Windbg, kann es nützlich sein, einige Allgemeine Diagnose-Befehle vor der Entscheidung, wo, um tiefer zu Graben. Diese sollten Ihre ersten Schritte:

    .logopen <filename>    (See also .logappend)
.lastevent             See why the process halted and on what thread
u                      List disassembly near $eip on offending thread
~                      Status of all threads
Kb                     List callstack, including parameters
.logclose

    Diese Befehle in der Regel geben Ihnen einen überblick über das, was passiert ist, so dass Sie können weiter Graben. Im Umgang mit Bibliotheken, in denen Sie nicht Quelle, versenden die daraus resultierende log-Datei an den Hersteller zusammen mit der build # der binären Bibliothek sollte ausreichend sein, für Sie zu verfolgen es sich um ein bekanntes Problem, wenn es einen gibt.

    InformationsquelleAutor Michael Labbé

  3. 2

    Dies passiert meist dann, wenn ein client CreateFile für ein vorhandenes Rohr und alle vorhandenen pipe-Instanzen beschäftigt. An dieser Stelle CreateFile ein Fehler zurückgegeben, und der Fehlercode ist ERROR_PIPE_BUSY. Das richtige an dieser Stelle ist zu nennen, WaitNamedPipe mit einem timeout-Wert zu warten für eine pipe-Instanz verfügbar sind.

    Das problem in der Regel passiert, wenn mehr als ein client versucht, eine Verbindung mit der named pipe zur gleichen Zeit.

    InformationsquelleAutor steve

  4. 1

    Dies ist eine hervorragende Ressource für die Verwendung von WinDbg analysieren Abstürze, die Ihnen von nutzen sein kann: http://www.networkworld.com/article/3100370/windows/how-to-solve-windows-10-crashes-in-less-than-a-minute.html

    Der Artikel ist für Windows 10, aber es enthält links zu ähnlichen Informationen, die für frühere Versionen von Windows.

    Der link ist kaputt.
    vielen Dank für den Hinweis. Ich habe aktualisiert die Antwort.

    InformationsquelleAutor boot13

  5. 0

    Ich gehe davon aus, dass die 3rd-party-dll für native (Sonst, nur mit Reflektor)

    Vor der Verwendung von WinDbg, um das Speicherabbild zu analysieren, versuchen Sie es mit Process Monitor (von SysInternals, freeware) zum überwachen Ihres Prozesses Aktivität. wenn es schlägt fehl, weil ein Dateisystem Problem, können Sie genau sehen, was das problem verursacht und was es versucht zu tun, bevor der Vorgang abgebrochen.

    Wenn Prozess-Monitor nicht genug, als Sie können, Debuggen Sie Ihren Prozess. aber um zu sehen, einige aussagekräftige Informationen über die 3rd-party-dll, die Sie brauchen, es ist pdb.

    Nachdem Sie die richtigen debug-Symbole, können Sie die Aufrufliste anzeigen, indem Sie mit dem k-Befehl oder eine seiner Variationen (mal wieder, ich nehme an, Sie reden von native code). wenn Ihr Prozess ist in der Tat Absturz, weil dieser dll als untersuchen Sie die Parameter, die Sie übergeben, um seine Funktion, um sicherzustellen, dass das problem nicht auf Ihrer Seite. Ich denke, dass weiter unten im Aufruf-stack, erreichen Sie einige Win32-API - überprüfen Sie die Parameter, die die dll-Funktion übergeben wird, versucht zu sehen, ob etwas "riecht". Wenn du die dll ' s eigenes symbol, das Sie untersuchen können, es ist Funktion lokalen Variablen (dv), die Ihnen einige weitere Informationen.

    Ich hoffe, ich gab Ihnen einen guten Ausgangspunkt.

    InformationsquelleAutor Moshe Levi

Schreibe einen Kommentar