Not
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Senast uppdaterad:
- Den 27 maj 2007
Du kommer till en intressant brytpunkt när du felsöker din drivrutin, bara för att felsökningsprogrammet ska pausa under mycket lång tid medan den försöker läsa in symboler för drivrutiner som du inte äger och som inte ens spelar någon roll för felsökningsuppgiften till hands. Vad är det som händer?
Som standard läses symboler in av felsökningsprogrammet när de behövs. (Detta kallas uppskjuten symbolinläsning eller lat symbolinläsning.) Felsökningsprogrammet letar efter symboler när det kör ett kommando som anropar för visning av symboler. Detta kan inträffa vid en brytpunkt om du har angett en klockvariabel som inte är giltig i den aktuella kontexten, till exempel en funktionsparameter eller lokal variabel som inte finns i den aktuella stackramen, eftersom de blir ogiltiga när kontexten ändras. Det kan också inträffa om du helt enkelt skriver ett symbolnamn fel eller kör ett ogiltigt felsökningskommando – felsökningsprogrammet börjar leta efter en matchande symbol.
Varför tar det ibland så lång tid? Det beror på om symbolnamnet är kvalificerat eller okvalificerat. Ett kvalificerat symbolnamn föregås av namnet på modulen som innehåller symbolen, till exempel myModule!myVar. Ett okvalificerat symbolnamn anger inte ett modulnamn, till exempel myOtherVar.
När det gäller det kvalificerade namnet letar felsökaren efter symbolen i den angivna modulen och läser in modulen (förutsatt att modulen finns och innehåller symbolen om modulen inte redan har lästs in). Detta sker ganska snabbt.
När det gäller ett okvalificerat namn vet felsökaren inte vilken modul som innehåller symbolen, så den måste titta i alla. Debuggern kontrollerar först alla inlästa moduler efter symbolen, och om symbolen inte kan matchas i någon inläst modul, fortsätter debuggern sin sökning genom att ladda alla oladdade moduler, med start från nedströmslagret och slutligen symbolservern, om du använder en. Det här kan ta mycket tid.
Så här förhindrar du automatisk inläsning för okvalificerade symboler
Alternativet SYMOPT_NO_UNQUALIFIED_LOADS inaktiverar eller aktiverar felsökningsprogrammets automatiska inläsning av moduler när det söker efter en okvalificerad symbol. När SYMOPT_NO_UNQUALIFIED_LOADS har angetts och felsökaren försöker matcha en okvalificerad symbol söker den bara igenom moduler som redan har lästs in och slutar söka när den inte kan matcha symbolen, i stället för att läsa in borttagna moduler för att fortsätta sökningen. Det här alternativet påverkar inte sökning efter kvalificerade namn.
SYMOPT_NO_UNQUALIFIED_LOADS är inaktiverat som standard. Om du vill aktivera det här alternativet använder du kommandoradsalternativet -snul eller, medan felsökningsprogrammet körs, använder du .symopt+0x100 eller .symopt-0x100 för att aktivera respektive inaktivera alternativet.
Prova det här experimentet om du vill se effekten av SYMOPT_NO_UNQUALIFIED_LOADS:
- Aktivera brusande symbolinläsning (SYMOPT_DEBUG) med hjälp av kommandoradsalternativet -n eller, om felsökningsprogrammet redan körs, använder du .symopt+0x80000000 eller kommandot !sym noisy debugger extension. SYMOPT_DEBUG instruerar felsökaren att visa information om dess sökning efter symboler, till exempel namnet på varje modul när den läses in eller ett felmeddelande om felsökaren inte kan hitta en fil.
- Instruera felsökningsprogrammet att utvärdera en icke-existerande symbol (till exempel skriv ?asdasdasd). Felsökaren bör rapportera flera fel när den söker efter den obefintliga symbolen.
- Aktivera SYMOPT_NO_UNQUALIFIED_LOADS med hjälp av .symopt+0x100.
- Upprepa steg 2. Felsökaren bör endast söka i inlästa moduler efter den obefintliga symbolen, och den bör slutföra uppgiften mycket snabbare.
- Om du vill inaktivera SYMOPT_DEBUG använder du .symopt-0x80000000 eller kommandot !sym quiet debugger extension.
Det finns ett antal alternativ för att styra hur felsökaren läser in och använder symboler. En fullständig lista över symbolalternativ och hur du använder dem finns i "Ange symbolalternativ" i onlinedokumentationen med felsökningsverktyg för Windows. Den senaste versionen av paketet Felsökningsverktyg för Windows är tillgänglig som en kostnadsfri nedladdning från webben, eller så kan du installera paketet från Windows DDK, Platform SDK eller Customer Support Diagnostics CD.
Vad ska du göra?
- Om du vill påskynda symbolsökningen använder du kvalificerade namn i brytpunkter och felsökningskommandon när det är möjligt. Om du vill se en symbol från en känd modul kvalificerar du den med modulnamnet. Om du inte vet var symbolen finns använder du ett okvalificerat namn. För lokala variabler och funktionsargument använder du $ som modulnamn (till exempel $! MyVar).
- Om du vill diagnostisera orsakerna till långsam symbolinläsning aktiverar du störande symbolinläsning (SYMOPT_DEBUG) med hjälp av kommandoradsalternativet -n eller, om felsökningsprogrammet redan körs, med hjälp av .symopt+0x80000000 eller kommandot !sym noisy debugger extension.
- Om du vill förhindra att felsökaren söker efter symboler i oladdade moduler aktiverar du SYMOPT_NO_UNQUALIFIED_LOADS med hjälp av kommandoradsalternativet -snul eller, om felsökningsprogrammet redan körs, med hjälp av .symopt+0x100.
- Om du uttryckligen vill läsa in de moduler som du behöver för felsökningssessionen använder du felsökningskommandon som .reload eller ld.