Ich versuche herauszufinden, warum ein Prozess aufhört und lerne über verschiedene Tools wie Process Explorer , < a href="http://en.wikipedia.org/wiki/Process_Monitor"> Prozessmonitor und WinDbg .
Wie auch immer, ich versuche, WinDbg zu verwenden und nach dem Anhängen an meinen Prozess sagt der Debugger dies:
%Vor% Wenn ich !analyze -v ausführen, wird Folgendes angezeigt:
Ich bin ein Softwareentwickler (VB.NET / C #) ohne Erfahrung in dieser Ebene des Debuggens, also bin ich mir nicht sicher, was ich mache, aber es scheint, als ob WinDbg mit meinem Prozess verbunden ist und dann sofort brechen. Dann, wenn ich eine Analyse mache, denkt es, dass der Breakpoint (den er gerade gesetzt hat) das Problem mit der Anwendung ist?
Wie soll ich WinDbg verwenden, um einfach an einen Prozess anzuhängen und ihn zu analysieren?
(Gibt es auch irgendwelche guten Bücher / Tutorials, um mit dieser Stufe des Debuggens und WinDbg zu beginnen?)
WinDbg ist ein Debugger für den Benutzer und den Kernel-Modus, versteht aber verwalteten Code nicht wirklich und daher ist der Befehl !analyze nur von begrenztem Nutzen. Wenn Sie verwaltete Anwendungen mit WinDbg debuggen möchten, benötigen Sie eine Möglichkeit, WinDbg die internen Strukturen von verwaltetem Code verständlich zu machen. Es gibt eine Reihe von Erweiterungs-DLLs, die dies ermöglichen. Das .NET Framework wird mit sos.dll ausgeliefert und es gibt Downloads wie psscor2 .dll und sosex.dll .
SOS und PSSCOR2 bieten mehr oder weniger die gleichen Funktionen, während SOSEX neue Funktionen für das verwaltete Debugging hinzufügt. Hilfedateien für jeden von diesen sind verfügbar von WinDbg. Z.B. Um die Hilfe für SOS zu erhalten, können Sie den Befehl !sos.help verwenden.
Sie müssen entweder SOS oder PSSCOR2 und möglicherweise SOSEX laden, um eine verwaltete Anwendung mit WinDbg zu debuggen. Z.B. Wenn Sie SOS laden möchten, verwenden Sie den Ladebefehl wie folgt
.loadby sos clr
Dadurch wird SOS vom Speicherort der .NET-Laufzeit geladen. Beachten Sie, dass die Laufzeit in Silverlight mscorwks in .NET 2 und coreclr genannt wird. Wenn Sie also eine dieser Methoden verwenden, müssen Sie den Befehl .loadby entsprechend ändern.
WinDbg benötigt Symbole, um zusätzliche Informationen anzuzeigen. Dies ist besonders wichtig für nicht verwalteten Code. Sie können den Befehl .symfix verwenden, damit WinDbg Symbole bei Bedarf vom Microsoft-Symbolserver abrufen kann.
Da Ihre Anwendung blockiert ist, besteht eine gute Chance, dass Sie einen oder mehrere blockierte Threads haben. Sie können verwaltete Threads mit dem Befehl !threads (oder nur !t ) anzeigen. In .NET werden einfache Sperren intern über eine Struktur namens SyncBlocks implementiert. Sie können diese mit dem Befehl !syncblk anzeigen. Wenn Sie SOSEX geladen haben, kann der Befehl !dlk automatisch Deadlocks erkennen.
Wenn Sie mehr Informationen wünschen, gibt es ein paar Bücher und einige Blogs zum Lesen.
Bücher:
Blogs:
Videos:
Erweitertes Windows-Debugging wäre ein guter Anfang.
Wenn Windbg an einen Prozess angehängt wird, injiziert es einen Thread, der DbgBreakPoint aufruft. Das siehst du. Sie können ~ verwenden, um laufende Threads anzuzeigen, und dann ~ n, um zu einem anderen Thread zu wechseln. k gibt Ihnen einen Stack-Trace des aktuellen Threads, der Ihnen eine Vorstellung von dem Hang geben sollte.
Die int 3-Anweisung (cc in binary) ist eine der Möglichkeiten, wie Debugger Breakpoints in einer Anwendung setzen. Dieser Befehl erzeugt einen Interrupt, der die Ausführung des Programms unterbricht und dem Debugger die Möglichkeit gibt, auf diesen Interrupt zu reagieren. Sie müssen nur auswählen, dass die Ausführung fortgesetzt wird, bis Sie den Ort erreichen, an dem Ihr Programm hängt.