WinDbg медленно при отладке локального процесса (шаг за шагом)

Question

Это действительно сводит меня с ума. Я использую WinDbg в качестве основного отладчика. Он используется для отладки локальной службы (WinDbg работает локально, отладка службы на том же компьютере). Файлы PDB хранятся на локальном жестком диске. Доступ к исходному коду осуществляется через общий ресурс SMB.

Отладка работает в пакетном режиме, иногда она проходит хорошо, большую часть времени я продолжаю видеть невероятно раздражающее сообщение "* BUSY *", это происходит почти каждый раз, когда я выполняю "переход".

Есть идеи, что я могу сделать, чтобы ускорить процесс?

Спасибо

Answer 1

У меня была точно такая же проблема, и я смог увидеть значительное улучшение, настроив параметры символов. В частности, опция SYMOPT_NO_PUBLICS казалась наиболее важной, но я настроил несколько других связанных параметров. Я сделал следующее ...

.symopt-0x4 .symopt + 0х100 .symopt + 0x8000 .symopt-0x10000

... что:

-SYMOPT_DEFERRED_LOADS + SYMOPT_NO_UNQUALIFIED_LOADS + SYMOPT_NO_PUBLICS -SYMOPT_AUTO_PUBLICS

После всего этого у меня было значение битовой маски symopt 0x80028333, которое я теперь использую в качестве параметра командной строки WinDbg, например:

windbg.exe -sflags 0x80028333

Я еще не обнаружил, есть ли недостатки этого подхода. Возможно, в некоторых случаях использование SYMOPT_NO_PUBLICS приводит к потере информации, но до сих пор она работала хорошо для меня и определенно намного быстрее.

Параметры символов WinDbg MS Документация

Answer 2

Это может произойти, если у вас есть много неквалифицированных точек останова, которые отслеживают события загрузки модуля (созданные с помощью bu), сохраненные в вашем рабочем пространстве.
Также стоит проверить подключение к сети и размер кэша локальных символов

Answer 3

Когда в пути к символам содержится большое хранилище файлов, WinDbg может занять много времени в поисках несуществующих символов.Вы можете диагностировать это поведение, как предложил пользователь eran , запустив Process Monitor и наблюдая за файловыми операциями, выполняемыми WinDbg.

Это было крайнеБолевая точка для нашей организации, но я нашел обходной путь, подробно изложенный в этом вопросе: « WinDbg занимает очень много времени для загрузки символов; поиск в каждом каталоге в большой сети UNC хранилище символов »

Answer 4

Вместо использования «step-over», установите точку останова для следующей команды или даже аппаратную точку останова (используя ba)

Answer 5

Несколько вещей, чтобы попробовать:

• Используйте команду ! Sym noisy , чтобы показать более подробную информацию об изображениях и файлах pdbs, на которые ссылается windbg. Возможно, вы видите, что он получает доступ к сети больше, чем вы ожидаете, или что сетевой сервер недоступен и время ожидания запросов
• Убедитесь, что в пути вашего символа есть кэш
• Локально взять копию источников и добавить к исходному пути

Answer 6

Если он медленно вытаскивает файлы символов Windows из Интернета, рассмотрите возможность загрузки всех их на жесткий диск и указания WinDbg на их местоположение на нем.Лучше всего, чтобы файлы символов и исходные файлы вашей службы тоже были на локальном диске.

Answer 7

Обычно это случалось со мной, когда открывались несколько окон инструментов (локальные, часы, стек вызовов). Если эти окна открыты, WinDbg потратит циклы на обновление всех из них, используя медленный поиск символов в каждой команде 'step-over'.

В этом отношении использование только отладчика командной строки (ntsd) намного быстрее.