Wie finde ich heraus, welcher Thread der Besitzer meines Ereignis-Handle in windbg ist:
Ich renne
%Vor%und hole
%Vor%zurück, und da es keinen Namen gibt, habe ich nicht herausgefunden, wie ich den Besitzer dazu bringen kann, zu beweisen, auf welchen Thread mein Thread wartet
[Bearbeiten] Ich muss gegen einen Speicherabzug arbeiten, da der ursprüngliche Prozess auf dem Benutzercomputer neu gestartet werden muss, so dass eine Live-Sitzung nicht debuggt werden kann
Die beste Diskussion über das Thema, die ich bisher gefunden habe, ist auf diesem Blog , aber leider Am Ende benutzen wir verschiedene Lock-Methoden (ich benutze WaitForMultipleObjectsEx und die Beschreibung ist für WaitForSingleObject), und er scheint Zugang zu einem Live-Prozess zu haben.
Der Stacktrace meines Threads (derjenige, der auf etwas blockiert ist und wo ich nach dem aktuellen Besitzer suche) ist:
%Vor%Mit Blick auf den Callstack scheint der fragliche Stack einen ReaderWriterLock-Sperrmechanismus zu verwenden.
%Vor%
Wechseln Sie zu Thread 9 und verwenden Sie sos.dll , um ! Dso auszuführen, um das verwaltete ReaderWriterLock-Objekt auszugeben. Dann führe das auf dem ReaderWriterLock-Objekt aus. Ich glaube, dass es ein eigenes Thread-Feld gibt, das Sie abfragen können. Ich werde es testen und sehen.
Die alte Methode, dies zu ermitteln, besteht darin, ~ * e! Clrstack auszuführen und alle verwalteten Threads zu untersuchen, die auf eine Readerwriter-Sperre warten, und dann zu sehen, ob Sie den Thread finden, der denselben Thread eingegeben hat Funktion aber durch das Schloss (dh verschiedene Offset)
Vielen Dank, Aaron
Hinweis: Nicht sicher, ob es eine Möglichkeit gibt, Posts zu verlinken, aber diese ist sehr ähnlich zu Wie finde ich den Lockholder (Reader) meines ReaderWriterLock in windbg
Verwenden Sie den Befehl !htrace , um die Thread-ID abzurufen. Sie müssen zuerst, möglicherweise zu Beginn des Programms, die Sammlung von Spuren mit !htrace -enable aktivieren.
Die obige Ausgabe ist fiktiv, es wird für Ihr System anders sein. Aber es gibt Ihnen die Information, die Sie brauchen - die Thread-ID (in meinem Beispiel 0x00000b48).
Ich muss gegen eine Müllkippe arbeiten als die Der ursprüngliche Prozess muss neu gestartet werden auf dem Benutzer-Rechner, kann also nicht debuggen Live-Sitzung.
Ich bin mir nicht 100% sicher, aber ich denke, das wird funktionieren:
!htrace -enable ausführen
qd . Die ausführbare Datei wird fortgesetzt. Sie können das aus einem Kernel-Dump herausholen.
Nun, was das Kernel-Debugging angeht, sollte LiveKd von sysinternals ausreichen, aber leider ist es nur auf einem laufenden System verwendbar.
Es gibt auch einen Speichererfassungs-Tool im Kernel-Modus , das nützlich sein könnte, um einen Dump mit (statt dessen) für eine spätere Inspektion zu machen.
Andernfalls wird die Handle-Traceerstellung (! htrace -enable) und (wenn der Code für einen bestimmten Thread eindeutig ist) aktiviert, und die Handle-Eigentümerschaft könnte aus einer Stack-Ablaufverfolgung geschlossen werden.