Freigeben über


Kombinieren dieser Methode mit Remotedebugging

Es ist manchmal nützlich, den Benutzermodusdebugger über den Kerneldebugger zu steuern und den Benutzermodusdebugger gleichzeitig als Debugserver zu verwenden.

Diese Konfiguration ist beispielsweise hilfreich, wenn sich Ihre Benutzermodussymbole auf einem Symbolserver befinden. In der Standardkonfiguration zur Steuerung des Benutzermodus-Debuggers von einem Kernel-Debugger aus kann die Interaktion der beiden Debugger zu winzigen Synchronisierungsfehlern führen, die die Symbolserverauthentifizierung verhindern können. Die hier beschriebene komplexere Konfiguration kann dieses Problem vermeiden.

Hinweis Zur Beschreibung dieses Szenarios bezieht sich die Zielanwendung auf die Benutzermodusanwendung, die gedebuggt wird, der Zielcomputer verweist auf den Computer, der die Zielanwendung und den CDB- oder NTSD-Prozess enthält, und der Hostcomputer verweist auf den Computer, der den Kerneldebugger enthält.

Um diese Technik zu verwenden, müssen Sie folgendes ausführen:

  1. Starten Sie NTSD oder CDB auf dem Zielcomputer mit den Befehlszeilenoptionen -ddefer und -server, und geben Sie die gewünschten Transportoptionen an. Die Option -server muss der erste Parameter in der Befehlszeile sein.

    Sie können sie z. B. mithilfe der folgenden Syntax an einen ausgeführten Prozess anfügen.

    ntsd -server ServerTransport -ddefer [-y UserSymbolPath] -p PID 
    

    Alternativ können Sie einen neuen Prozess als Ziel starten, indem Sie die folgende Syntax verwenden.

    ntsd -server ServerTransport -ddefer [-y UserSymbolPath] ApplicationName 
    

    Wenn Sie dies als Postmortemdebugger installieren, verwenden Sie die folgende Syntax. Beachten Sie, dass Sie die Registrierung manuell bearbeiten müssen, um einen Postmortemdebugger zu installieren, der den Parameter "-server" enthält. Weitere Informationen finden Sie unter Aktivieren des Postmortem-Debuggings.

    ntsd -server ServerTransport -ddefer [-y UserSymbolPath] 
    

    Informationen zu den verfügbaren Transportoptionen finden Sie unter Aktivieren eines Debugservers.

  2. Starten Sie WinDbg oder KD auf dem Hostcomputer, als würden Sie den Zielcomputer debuggen, aber nicht tatsächlich auf den Zielcomputer einbrechen. Verwenden Sie die folgende Syntax, um WinDbg zu verwenden.

    windbg [-y KernelSymbolPath] [-k ConnectionOptions] 
    

    Weitere Informationen zu diesem Schritt finden Sie unter Live Kernel-Mode Debugging mit WinDbg (Classic)

    .

  3. Starten Sie WinDbg oder CDB als Debugclient mit den gleichen Transportoptionen, die zum Starten des Servers verwendet werden. Dieser Debugclient kann entweder auf dem Hostcomputer oder auf einem dritten Computer ausgeführt werden.

    cdb -remote ClientTransport 
    

    Weitere Informationen zu diesem Schritt finden Sie unter Aktivieren eines Debugclients.

  4. Sobald die Debugger ausgeführt werden und die Input> Eingabeaufforderung im Kerneldebugger angezeigt wird, verwenden Sie den Befehl .sleep (Debugger anhalten), um die Debugger anzuhalten und den Zielcomputer einige Sekunden lang ausführen zu lassen. Dadurch erhält der Zielcomputer Zeit zum Verarbeiten des Remotetransportprotokolls, wobei die Verbindung zwischen dem Remoteserver im Benutzermodus und dem Remoteclient hergestellt wird.

Wenn Sie CDB als Debugger im Benutzermodus verwenden, bleibt das mit CDB verknüpfte Eingabeaufforderungsfenster gesperrt und ist nicht verfügbar, während das Debuggen fortgesetzt wird. Wenn Sie NTSD verwenden, wird kein zusätzliches Fenster erstellt, obwohl NTSD eine Prozess-ID auf dem Zielcomputer zugeordnet hat.

Die vier Modi und die Methoden des Wechselns zwischen ihnen, die im Thema "Wechselmodi" beschrieben werden, gelten in diesem Kombinationsszenario mit den folgenden Unterschieden:

  • Es gibt zwei verschiedene Debugmodi für den Benutzermodus. Wenn der Zielcomputer ausgeführt wird, wird der Debugserver wie in jeder anderen Remotedebuggingsitzung vom Debugclient gesteuert; dies wird als remotegesteuertes Debuggen im Benutzermodus bezeichnet. Wenn der Kernelmodusdebugger auf dem Zielcomputer unterbrochen wird und die Input> Eingabeaufforderung angezeigt wird, wird der Benutzermodusdebugger vom Kerneldebugger gesteuert; dies wird als kernelgesteuertes Benutzermodusdebugging bezeichnet.

  • Diese beiden Modi sind nie gleichzeitig verfügbar. Wenn der Kerneldebugger auf dem Zielcomputer beschädigt ist, kann der Zielcomputer das Remote-Transportprotokoll nicht verarbeiten, auch wenn der Benutzermodusdebugger aktiv ist. Daher kann der Benutzermodusdebugger über diese Verbindung keine Remote-Eingaben empfangen.

  • Wenn sich Ihre Benutzermodussymbole auf einem Symbolserver befinden, sollten alle Debuggerbefehle, die den Symbolzugriff erfordern, im remote gesteuerten Benutzermodusdebuggingmodus ausgegeben werden.

  • Um vom kernelgesteuerten Benutzermodusdebugging zum remotegesteuerten Benutzermodusdebugging zu wechseln, verwenden Sie den Befehl .sleep (Pause Debugger). Wenn der Benutzermodusdebugger über den Energiesparmodus-Befehl reaktiviert wird, befindet er sich im remote gesteuerten Benutzermodus-Debuggingmodus.

  • Um vom remotegesteuerten Benutzermodusdebugging zum Kernelmodusdebugging zu wechseln, geben Sie einen beliebigen Befehl aus der Input> Eingabeaufforderung ein. Wenn diese Eingabeaufforderung nicht sichtbar ist, wechseln Sie zum Kernelmodusdebugging, und verwenden Sie dann den Befehl g (Go) an der kd> Eingabeaufforderung.

Intern bietet ein Benutzermodusdebugger, der mit "-ddefer" gestartet wurde, die erste Priorität für Eingaben vom Debugclient und die zweite Priorität für eingaben aus dem Kerneldebugger. Es kann jedoch nie ein Konflikt zwischen gleichzeitigen Eingaben auftreten, da die Remoteverbindung nicht verfügbar ist, wenn der Kerneldebugger auf dem Zielcomputer unterbrochen wurde.