Ich habe mehrere Tage damit verbracht, das Laden von Symbolen beim Debuggen von Absturzabbildern mit @ zu beschleunige WinDbg, und ich komme an einem bestimmten Problem nicht vorbei.

Das Problem ist, dass WinDbg buchstäblich Stunden damit verbringt, nach Symbolen für ein Modul im Speicherauszug zu suchen, wenn sie in keinem zugänglichen Symbolspeicher oder auf dem Symbolserver vorhanden sind (z. B. in Modulen von Drittanbietern ohne verfügbare Symbole).

Ich habe meinen Symbolpfad richtig eingerichtet, um die Suchreihenfolge und die Cache-Verzeichnisse richtig einzustellen:

.sympath cache*C:\SymbolCache1;\\our.corp\SymbolStore;SRV*C:\SymbolCache2*http://msdl.microsoft.com/download/symbols

Laufen mit!sym noisy und.reload /f Ich kann es sehen

SYMSRV:  Notifies the client application that a proxy has been detected. 
SYMSRV:  Connecting to the Server: http://msdl.microsoft.com/download/symbols. 
SYMSRV:  Successfully connected to the Server. 
SYMSRV:  Sending the information request to the server. 
SYMSRV:  Successfully sent the information request to the server. 
SYMSRV:  Waiting for the server to respond to a request. 
SYMSRV:  Successfully received a response from the server. 
SYMSRV:  Closing the connection to the Server. 
SYMSRV:  Successfully closed the connection to the Server. 
SYMSRV:  c:\SymbolCache1\Some3rdParty.dll\0060D200cd1000\Some3rdParty.dll not found 
SYMSRV:  c:\SymbolCache2\Some3rdParty.dll\0060D200cd1000\Some3rdParty.dll not found 
SYMSRV:  http://msdl.microsoft.com/download/symbols/Some3rdParty.dll/0060D200cd1000/Some3rdParty.dll not found 
<---- !!!! hanging here with *BUSY* showing in WinDbg

By runningProcess Monitor an dem Punkt, an dem es hängt, kann ich sehen, dass WinDbg sucht, was zu sein scheintjedes Verzeichnis in unserem riesigen Netzwerksymbolspeicher (\ our.corp \ SymbolStore), der nach Symbolen sucht, auch in Verzeichnissen für Module, die eindeutig keine Beziehung zueinander haben.

Seltsam ist, dass Sie in WinDbg sehen können, dass es den Zeitstempel des Moduls (0060D200cd1000) extrahiert und diesen verwendet, um den erwarteten Speicherort in lokalen Verzeichnissen und auf dem MS-Symbolserver zu suchen. Ich kann nicht herausfinden, warum ein vollständiger Scan unseres (massiven) Netzwerksymbolspeichers durchgeführt wird. Vielleicht hat es etwas Einzigartiges an der Behandlung von UNC-Pfaden?

Diese Suche kann pro Symbol 15 Minuten oder länger dauern. Wenn auf dem Dump viele Symbole fehlen, kann dies zu einem @ führe!analyze -v dauert Stunden (wenn Sie die Visual Studio-Integration von WinDbg verwenden, tritt der Hang auf, sobald Sie einen Absturzabbild laden, da die Integration aus irgendeinem Grund versucht, alle Symbole sofort zu laden, obwohl.symopt die Einstellungen)

Dieses Problem lässt sich auch leicht reproduzieren, wenn Sie versuchen, Symbole für einen nicht vorhandenen, erfundenen Modulnamen zu laden, z..reload /f bogus.dll.

Hier sind meine WinDbg .symopt Einstellungen:

0:000> .symopt
Symbol options are 0x30337:
  0x00000001 - SYMOPT_CASE_INSENSITIVE
  0x00000002 - SYMOPT_UNDNAME
  0x00000004 - SYMOPT_DEFERRED_LOADS
  0x00000010 - SYMOPT_LOAD_LINES
  0x00000020 - SYMOPT_OMAP_FIND_NEAREST
  0x00000100 - SYMOPT_NO_UNQUALIFIED_LOADS
  0x00000200 - SYMOPT_FAIL_CRITICAL_ERRORS
  0x00010000 - SYMOPT_AUTO_PUBLICS
  0x00020000 - SYMOPT_NO_IMAGE_SEARCH

Ich habe überall darüber nachgedacht, dass es eine Flagge geben muss, um dies zu kontrollieren, aber ich kann sie anscheinend nicht finden.

Ein paar Dinge:

Dies ist kein Problem mit der Netzwerkgeschwindigkeit oder dem Mangel an lokalem Symbol-Cache. Das Problem tritt nur bei Symbolen auf, die nicht gefunden werden können, und nur beim UNC-Symbolspeicher (z. B. nicht beim Microsoft-Symbolserver). Ich habe bereits SYMOPT_NO_PUBLICS anstelle von SYMOPT_AUTO_PUBLICS ausprobiert. Ich habe mit dem @ -Zeichen überprüft, ob mein Symbolpfad dem entspricht, den ich erwartet habsympath Befehl. Ich habe es auch mit dem @ versuc_NT_SYMBOL_PATH Umgebungsvariable statt. Ich weiß, dass ich bestimmte Symbole über eine Konfigurationsdatei ausschließen kann, aber dies ist keine praktikable Lösung, da manchmal der fehlende Symbolname nicht im Voraus bekannt ist. Ich habe gesehen, dass jemand anderes im Internet dasselbe Problem hatte und erwähnte es in einem Microsoft-Forum in einem Beitrag mit dem Titel " Schlechte Leistung von WinDbg 6.11.1.404, wenn auf einen großen Symbolcache verwiesen wird "erhielt aber keine Hilfe.