Als jemand, der gerade beginnt, die Feinheiten des Computer-Debuggens zu lernen, kann ich für das Leben von mir nicht verstehen, wie man den Stack-Text eines Speicherauszugs in Windbg liest. Ich habe keine Ahnung, wo ich damit anfangen soll, wie ich sie interpretiere oder wie ich vorgehe. Kann jemand dieser armen Seele eine Richtung geben?
ie (die einzige Dump, die ich tatsächlich bei mir habe)
%Vor%Ich weiß, dass das Problem mit dem Nvidia-Display-Treiber zu tun hat, aber was ich wissen möchte, ist, wie man den Stack tatsächlich liest (zB was ist b69dd8f4?): - [
Zuerst müssen die richtigen Symbole konfiguriert werden. Mit den Symbolen können Sie Speicheradressen den Funktionsnamen zuordnen. Dazu müssen Sie in Ihrem Rechner einen lokalen Ordner anlegen, in dem Sie einen lokalen Cache mit Symbolen speichern (zB: C: \ Symbole). Dann müssen Sie den Symbol-Server-Pfad angeben. Gehen Sie dazu einfach zu: Datei & gt; Symbol Dateipfad und geben Sie Folgendes ein:
%Vor%Sie finden weitere Informationen zur korrekten Konfiguration der Symbole hier .
Nachdem Sie den Symbols-Server richtig konfiguriert haben, können Sie den Minidump öffnen von: Datei & gt; Öffnen Sie Crash Dump.
Sobald der Minidump geöffnet ist, wird auf der linken Seite der Befehlszeile der Thread angezeigt, der beim Erstellen des Dumps ausgeführt wurde. Wenn Sie sehen möchten, was dieser Thread ausführte, geben Sie Folgendes ein:
%Vor%Dies kann einige Zeit dauern, bis Sie die erforderlichen öffentlichen Microsoft-bezogenen Symbole zum ersten Mal herunterladen. Sobald alle Symbole heruntergeladen sind, erhalten Sie etwas wie:
%Vor%Wo:
Möglicherweise sehen Sie auch etwas wie
%Vor%Dies zeigt an, dass Sie nicht das richtige Symbol für diese DLL haben und daher nur den Offset der Methode sehen können.
Also, was ist ein Callstack?
Stellen Sie sich vor, Sie haben diesen Code:
%Vor%In diesem Code wird method2 im Prinzip eine Exception werfen, da wir versuchen, durch 0 zu teilen, was zum Absturz des Prozesses führt. Wenn wir in diesem Fall einen Minidump bekommen, würden wir den folgenden Callstack sehen:
%Vor%Sie können von diesem Callstack aus folgen, dass "main" "method1" genannt hat und dann "method2" aufgerufen hat und es fehlgeschlagen ist.
In Ihrem Fall haben Sie diesen Callstack (was wahrscheinlich das Ergebnis des Befehls "kb" ist)
%Vor%Die erste Spalte gibt den untergeordneten Frame-Zeiger an, die zweite Spalte gibt die Rücksprungadresse der auszuführenden Methode an, die nächsten drei Spalten zeigen die ersten drei Parameter, die an die Methode übergeben wurden, und der letzte Teil ist der DLL-Name (nv4_disp) und den Offset der Methode, die ausgeführt wird (+ 0x48b94). Da Sie die Symbole nicht haben, können Sie den Methodennamen nicht sehen. Ich bezweifle, dass NVIDIA öffentlichen Zugang zu ihren Symbolen bietet, also kann ich Ihnen sagen, dass Sie von hier aus nicht viele Informationen bekommen können.
Ich empfehle Ihnen, "kpn 200" auszuführen. Dies zeigt Ihnen den vollständigen Aufrufstack und Sie können möglicherweise den Ursprung der Methode sehen, die diesen Absturz verursacht hat (wenn es eine Microsoft DLL war, sollten Sie die richtigen Symbole in den von mir bereitgestellten Schritten haben).
Zumindest weißt du, dass es sich um einen NVIDIA-Fehler handelt ;-) Versuche, die DLLs dieses Treibers auf die neueste Version zu aktualisieren.
Falls Sie mehr über WinDBG Debugging erfahren möchten, empfehle ich folgende Links:
Ein wirklich gutes Tutorial zum Interpretieren eines Stack Trace finden Sie hier:
Aber selbst mit einem solchen Tutorial kann es sehr schwierig (oder fast unmöglich) sein, einen Stack Dump ohne die richtigen verfügbaren / geladenen Symbole zu interpretieren.
Es kann hilfreich sein, ein Beispiel für den Stack anzugeben, den Sie lesen möchten. Ein guter Tipp ist, dass Sie korrekte Debug-Symbole für alle im Stack angezeigten Module haben. Dazu gehören Symbole für Module im Betriebssystem, Microsoft hat ihren Symbolserver öffentlich verfügbar gemacht.
Tags und Links multithreading stack-trace windbg