Vermeiden von Debuggersuchen nach nicht benötigten Symbolen

Letzte Aktualisierung:

• 27. Mai 2007

Beim Debuggen des Treibers gelangen Sie zu einem interessanten Haltepunkt, nur um den Debugger für eine sehr lange Pause zu halten, während er versucht, Symbole für Treiber zu laden, die Sie nicht besitzen und die für die debug-Aufgabe nicht einmal wichtig sind. Woran liegt das?

Standardmäßig werden Symbole nach Bedarf vom Debugger geladen. (Dies wird als verzögertes Laden von Symbolen oder verzögertes Laden von Symbolen bezeichnet.) Der Debugger sucht nach Symbolen, wenn er einen Befehl ausführt, der für die Anzeige von Symbolen aufruft. Dies kann an einem Haltepunkt passieren, wenn Sie eine watch Variable festgelegt haben, die im aktuellen Kontext ungültig ist, z. B. einen Funktionsparameter oder eine lokale Variable, die im aktuellen Stapelrahmen nicht vorhanden ist, da sie ungültig wird, wenn sich der Kontext ändert. Dies kann auch vorkommen, wenn Sie einfach einen Symbolnamen falsch eingeben oder einen ungültigen Debuggerbefehl ausführen. Der Debugger sucht nach einem übereinstimmenden Symbol.

Warum dauert das manchmal so lange? Dies hängt davon ab, ob der Symbolname qualifiziert oder nicht qualifiziert ist. Einem qualifizierten Symbolnamen wird der Name des Moduls vorangestellt, das das Symbol enthält, z. B. myModule!myVar. Ein nicht qualifizierter Symbolname gibt keinen Modulnamen an, z. B. myOtherVar.

Im Fall des qualifizierten Namens sucht der Debugger nach dem Symbol im angegebenen Modul und lädt das Modul, wenn das Modul noch nicht geladen ist (vorausgesetzt, das Modul ist vorhanden und enthält das Symbol). Dies geschieht ziemlich schnell.

Bei einem nicht qualifizierten Namen "weiß" der Debugger nicht, welches Modul das Symbol enthält, sodass er in allen nachsehen muss. Der Debugger überprüft zunächst alle geladenen Module auf das Symbol. Wenn es dann nicht mit dem Symbol in einem geladenen Modul übereinstimmen kann, setzt der Debugger seine Suche fort, indem er alle entladenen Module lädt, beginnend mit dem Downstreamspeicher und dem Symbolserver, falls Sie einen verwenden. Dies kann natürlich viel Zeit in Anspruch nehmen.

Verhindern des automatischen Ladens für nicht qualifizierte Symbole

Die Option SYMOPT_NO_UNQUALIFIED_LOADS deaktiviert oder aktiviert das automatische Laden von Modulen im Debugger, wenn nach einem nicht qualifizierten Symbol gesucht wird. Wenn SYMOPT_NO_UNQUALIFIED_LOADS festgelegt ist und der Debugger versucht, ein nicht qualifiziertes Symbol zuzuordnen, sucht er nur module, die bereits geladen wurden, und beendet die Suche, wenn er nicht mit dem Symbol übereinstimmen kann, anstatt entladene Module zu laden, um die Suche fortzusetzen. Diese Option wirkt sich nicht auf die Suche nach qualifizierten Namen aus.

SYMOPT_NO_UNQUALIFIED_LOADS ist standardmäßig deaktiviert. Um diese Option zu aktivieren, verwenden Sie die Befehlszeilenoption -snul , oder verwenden Sie während der Ausführung des Debuggers .symopt+0x100 oder .symopt-0x100 , um die Option zu aktivieren bzw. zu deaktivieren.

Um die Auswirkungen von SYMOPT_NO_UNQUALIFIED_LOADS zu sehen, probieren Sie dieses Experiment aus:

1. Aktivieren Sie das laden von verrauschten Symbolen (SYMOPT_DEBUG), indem Sie die Befehlszeilenoption -n verwenden, oder verwenden Sie, wenn der Debugger bereits ausgeführt wird, .symopt+0x80000000 oder den Befehl !sym noisy debugger extension. SYMOPT_DEBUG weist den Debugger an, Informationen zur Suche nach Symbolen anzuzeigen, z. B. den Namen jedes Moduls beim Laden oder eine Fehlermeldung, wenn der Debugger keine Datei finden kann.
2. Weisen Sie den Debugger an, ein nicht vorhandenes Symbol auszuwerten (geben Sie z. B. ?asdasdasd ein). Der Debugger sollte zahlreiche Fehler melden, während er nach dem nicht vorhandenen Symbol sucht.
3. Aktivieren Sie SYMOPT_NO_UNQUALIFIED_LOADS mithilfe von .symopt+0x100.
4. Wiederholen Sie Schritt 2. Der Debugger sollte nur geladene Module nach dem nicht vorhandenen Symbol durchsuchen und die Aufgabe viel schneller abschließen.
5. Um SYMOPT_DEBUG zu deaktivieren, verwenden Sie .symopt-0x80000000 oder den Befehl !sym quiet debugger extension.

Es stehen eine Reihe von Optionen zur Verfügung, um zu steuern, wie der Debugger Symbole lädt und verwendet. Eine vollständige Liste der Symboloptionen und deren Verwendung finden Sie unter "Festlegen von Symboloptionen" in der Onlinedokumentation zu Debugtools für Windows. Die neueste Version des Pakets Debugtools für Windows steht als kostenloser Download aus dem Web zur Verfügung, oder Sie können das Paket über die CD Windows DDK, Platform SDK oder Customer Support Diagnostics installieren.

Wie sollten Sie vorgehen?

• Um die Suche nach Symbolen zu beschleunigen, verwenden Sie nach Möglichkeit qualifizierte Namen in Haltepunkten und Debuggerbefehlen. Wenn Sie ein Symbol aus einem bekannten Modul sehen möchten, qualifizieren Sie es mit dem Modulnamen. Wenn Sie nicht wissen, wo sich das Symbol befindet, verwenden Sie einen nicht qualifizierten Namen. Verwenden Sie $ für lokale Variablen und Funktionsargumente als Modulnamen (z. B. $! MyVar).
• Um die Ursachen des langsamen Ladens von Symbolen zu diagnostizieren, aktivieren Sie das laden von verrauschten Symbolen (SYMOPT_DEBUG) mithilfe der Befehlszeilenoption -n oder, wenn der Debugger bereits ausgeführt wird, mithilfe von .symopt+0x80000000 oder dem Befehl !sym noisy debugger extension.
• Um zu verhindern, dass der Debugger in entladenen Modulen nach Symbolen sucht, aktivieren Sie SYMOPT_NO_UNQUALIFIED_LOADS mithilfe der Befehlszeilenoption -snul oder, wenn der Debugger bereits ausgeführt wird, mithilfe von .symopt+0x100.
• Verwenden Sie Debuggerbefehle wie .reload oder ld, um die Module, die Sie für Ihre Debugsitzung benötigen, explizit zu laden.

Weitere Informationen

WDK herunterladen

Debuggingtools für Windows

Erste Schritte mit Windows-Debugging