Я провел несколько дней, пытаясь ускорить загрузку символов при отладке аварийных дампов с помощьюWinDbgи я не могу обойти конкретную проблему.

Проблема в том, что когда символы для модуля в дампе не существуют ни в одном доступном хранилище символов или в расположении сервера символов (например, это сторонние модули без доступных символов), WinDbg будет тратить буквально часы на их поиск.

Я правильно установил путь к символам, чтобы правильно установить порядок поиска и каталоги кеша:

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

Работает с!sym noisy а также.reload /f Я могу видеть:

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

ЗапустивМонитор процесса в тот момент, когда он зависает, я вижу, что WinDbg ищет то, что кажетсякаждый каталог в нашем гигантском сетевом хранилище символов (\ our.corp \ SymbolStore) ищем символы, даже в каталогах для модулей, которые явно не связаны.

Что странно, так это то, что в WinDbg вы можете видеть, что он извлекает временную метку модуля (0060D200cd1000) и использует ее для поиска ожидаемого расположения в локальных каталогах и на сервере символов MS. Я не могу понять, почему он делает полное сканирование нашего (массивного) сетевого хранилища символов. Возможно, есть что-то уникальное в том, как он обрабатывает пути UNC?

Этот поиск может занять 15 минут или более для каждого символа, и если в дампе много пропущенных символов, это может вызвать!analyze -v займет несколько часов (если вы используете интеграцию WinDbg с Visual Studio, это приводит к зависанию сразу после загрузки аварийного дампа, поскольку по какой-то причине интеграция пытается загрузить все символы сразу, несмотря на.symopt Настройки).

Эта проблема также легко воспроизводима, если вы пытаетесь загрузить символы для несуществующего имени готового модуля, например,.reload /f bogus.dll.

Вот мои настройки WinDbg .symopt:

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

Я огляделся и подумал, что должен быть какой-то флаг, чтобы контролировать это, но я не могу его найти.

Пара вещей:

Это не проблема со скоростью сети или отсутствием локального кэша символов. Проблема возникает только с символами, которые не могут быть найдены, и только с хранилищем символов UNC (например, не с сервером символов Microsoft)Я уже пробовал SYMOPT_NO_PUBLICS вместо SYMOPT_AUTO_PUBLICSЯ подтвердил, что мой путь к символу - это то, что я ожидаю, используяsympath команда. Я также пытался использовать_NT_SYMBOL_PATH переменная окружения вместо.Я знаю, что могу исключить определенные символы через файл конфигурации, но это нереализуемое решение, потому что иногда отсутствующее имя символа заранее неизвестноЯ видел, что у кого-то еще в Интернете была такая же проблема, и упоминал об этом на форуме Microsoft в посте под названием "Низкая производительность WinDbg 6.11.1.404, когда он указывает на большой символьный кеш"но не получил никакой помощи.