Debuggen von Sitzungs- und Ausführungsmodell
Die Debugger-Engine kann mehrere Ziele gleichzeitig debuggen. Eine Debugsitzung beginnt, wenn das Modul ein Ziel abruft, und wird fortgesetzt, bis alle Ziele verworfen wurden. Auf eine Debugsitzung kann nicht zugegriffen werden, während die Ziele ausgeführt werden, und auf sie kann zugegriffen werden, wenn das aktuelle Ziel angehalten wird. Die Engine kann nur verwendet werden, um Ziele zu untersuchen und zu bearbeiten, während auf die Sitzung zugegriffen werden kann.
Die Standard Schleife eines Debuggers besteht in der Regel darin, die Ausführung status festzulegen, die WaitForEvent-Methode aufzurufen und die generierten Ereignisse zu behandeln. Wenn WaitForEvent aufgerufen wird, kann auf die Sitzung nicht mehr zugegriffen werden.
Wenn ein Ereignis in einem Ziel auftritt, hält die Engine alle Ziele an, und die Sitzung wird zugänglich. Das Modul benachrichtigt dann die Ereignisrückrufe des Ereignisses und folgt den Ereignisfilterregeln. Die Ereignisrückrufe und Ereignisfilter bestimmen, wie die Ausführung im Ziel ablaufen soll. Wenn sie feststellen, dass das Modul in den Debugger einbrechen soll, gibt die WaitForEvent-Methode zurück, und die Sitzung bleibt zugänglich. Andernfalls setzt das Modul die Ausführung des Ziels in der von den Ereignisrückrufen und Ereignisfiltern festgelegten Weise fort, und die Sitzung kann wieder nicht mehr zugegriffen werden.
Für die Dauer des WaitForEvent-Aufrufs – insbesondere während der Benachrichtigung der Ereignisrückrufe und der Verarbeitung der Filterregeln – befindet sich das Modul in einem Zustand, der als "innerhalb einer Wartezeit" bezeichnet wird. In diesem Zustand kann WaitForEvent nicht aufgerufen werden (es ist nicht reentrant).
Beim Initiieren der Ausführung in einem Ziel sind zwei Schritte erforderlich: Festlegen der Ausführung status und anschließendes Aufrufen von WaitForEvent. Die Ausführung status kann mit der Methode SetExecutionStatus oder durch Ausführen eines Debuggerbefehls festgelegt werden, der die Ausführung status festlegt, z. B. g(Go) und p (Schritt).
Wenn eine Sequenz von Debuggerbefehlen zusammen ausgeführt wird, z. B. "g ; ? @$ip" – eine implizite Wartezeit tritt nach jedem Befehl auf, der eine Ausführung im Ziel erfordert, wenn dieser Befehl nicht der letzte Befehl in der Sequenz ist. Eine implizite Wartezeit kann nicht auftreten, wenn sich die Debugger-Engine im Zustand "innerhalb einer Wartezeit" befindet. In diesem Fall wird die Ausführung der Befehle beendet, und der aktuelle Befehl , der versucht hat, das implizite Warten zu verursachen, wird als Hinweis darauf interpretiert, wie die Ausführung im Ziel ablaufen soll. Die restlichen Befehle werden verworfen.
Hinweis Bei der Ermittlung, ob auf die Sitzung zugegriffen oder nicht zugegriffen werden kann, wird die eingeschränkte Ausführung eines Ziels (z. B. das Schrittweisen) vom Modul als Ausführung betrachtet. Wenn die eingeschränkte Ausführung abgeschlossen ist, kann auf die Sitzung zugegriffen werden.
Host-Engine
Beim Remotedebuggen können Sie mehrere Instanzen der Debugger-Engine verwenden. Genau eine dieser Instanzen verwaltet die Debugsitzung. diese instance wird als Host-Engine bezeichnet.
Alle Debuggervorgänge sind relativ zur Host-Engine, z. B. Das Laden von Symbolen und das Laden von Erweiterungen.