Разрешение символа WinDbg - PullRequest
       19

Разрешение символа WinDbg

34 голосов
/ 23 января 2009

При использовании WinDbg, где следует размещать файлы закрытых символов (pdb?)?

Моя ситуация такова: у меня есть DLL, которую я хочу отладить. У меня есть исходный код и файлы символов для этой библиотеки DLL. Эта DLL вызывается другой DLL (для которой у меня нет символов или источника), которая, в свою очередь, вызывается EXE-файлом (для которого у меня также нет символов или источника).

Моя проблема в том, что я получаю предупреждение, которое говорит

*** ПРЕДУПРЕЖДЕНИЕ: невозможно проверить контрольную сумму для C: \ TheProgram \ SomeSubfolder \ AnotherSubfolder \ MyDll.dll

Это предупреждение, по-моему, является причиной того, что я получаю сообщения следующего типа в стеке вызовов:

MyDLL! AClass :: + SomeHexAddress прекращение функции

Моя файловая структура выглядит примерно так:

exe: C: \ TheProgram \ program.exe

Вызывающий dll: C \ TheProgram \ SomeSubfolder \ caller. ???

Моя DLL, которую я хочу отладить: C: \ TheProgram \ SomeSubfolder \ AnotherSubfolder \ MyDll.dll

Примечание. Я установил путь к символьному файлу и исходный путь к файлу, в котором была создана отладочная DLL, в моей рабочей области на диске, отличном от exe. Но я скопировал файлы карты pdb + и поместил его в dll что я хотел отладить ..

Ответы [ 4 ]

45 голосов
/ 22 февраля 2009

Извините за поздний ответ.
В своем посте вы упоминаете, что видите следующее сообщение об ошибке.

*** WARNING: Unable to verify checksum for C:\TheProgram\SomeSubfolder\AnotherSubfolder\MyDll.dll

Вы также задаете вопрос: «Где я могу разместить свои символы для моей DLL в пути к символам?»

Вот ответ на первую проблему:

Шаги для определения несовпадающих символов.

  1. ! Sym noisy
  2. .reload
  3. x MyDll! * Класс *
    * Это перезагружает вашу dll, или вы можете набрать kb для отображения стека вызовов библиотеки DLL, которая также должна ее загрузить.
  4. ! Sym quiet
    * Возврат к исходной тихой загрузке символа

Также вы можете запустить

0:001> lmv m myDll  *(and examine the Checksum)

Примечание. Если у вас есть контрольная сумма, то Windbg может сопоставить контрольную сумму DLL с контрольной суммой PDB. В каждой среде разработки есть свой способ генерации контрольной суммы.

Вот ответ на вопросы о том, куда ставить PDB

Если в хранилище символов добавлен MyDll.pdb, вы можете использовать следующий синтаксис

.sympath SRV*c:\symcache*http://msdl.microsoft.com/download/symbols 

Как и предполагал Роджер выше ...

Однако, если у вас есть локальная PDB, вы можете сначала указать путь к PDB, прежде чем выходить на сервер символов, как этот

.sympath C:\TheProgram\SomeSubfolder\AnotherSubfolder\;SRV*c:\symcache*http://msdl.microsoft.com/download/symbols

Таким образом, Windbg должен выглядеть локально по отношению к вашему каталогу SomSubFolder, прежде чем пытаться использовать кэш Symbols Server.

Спасибо, Аарон

4 голосов
/ 23 января 2009

Неважно, куда вы помещаете файлы закрытых символов, если вы можете указать отладчику, где они находятся.

Предупреждение, которое вы видите не влияет на трассировку стека , но тот факт, что вы пропускаете символы для caller.DLL и app.EXE , делает .

Настройка символов в windbg (локально) так же проста, как и использование:

.sympath [+] path_to_pdbs
* и
.symfix + path_to_system_pdb_store

Вы видите:

MyDLL! AClass :: + SomeHexAddress прекращение функции
на самом деле ничего не значит, если SomeHexAddress разумно (и при условии, что MyDll.pdb был найден и загружен!) - это похоже на правильную запись в стеке вызовов.

Теперь мой вопрос: с какой проблемой вы застряли?

P.S. вам не нужен файл .map с windbg.

3 голосов
/ 23 января 2009

В рамках нашего процесса сборки мы копируем частные файлы PDB и выпущенные файлы EXE / DLL на сервер символов. В простейшем случае это просто UNC-путь, но вы можете настроить его для доступа по HTTP.

Чтобы скопировать выходные файлы, используйте программу SYMSTORE.EXE.

Затем настройте ваш отладчик (мы используем Visual Studio и WinDbg), чтобы найти этот путь. Для WinDbg самый простой способ сделать это - установить переменную окружения:

_NT_SYMBOL_PATH=
    SRV*C:\WebSymbols*http://msdl.microsoft.com/download/symbols;
    \\symsvr\Symbols

(все должно быть в одной строке)

Это настраивает WinDbg для просмотра на сервере Microsoft Symbol Server (кэширование файлов в C: \ WebSymbols), а также для поиска в локальном хранилище символов (\\symsvr\Symbols).

Мы также используем инструменты исходного сервера для хранения сведений SVN в файле PDB, а это означает, что мы можем вернуться к точному исходному файлу, который использовался для создания определенного выпуска. Посмотри в ...\Debugging Tools for Windows (x86)\srcsrv.

2 голосов
/ 23 января 2009

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

Из справки Microsoft:

-y SymbolPath 
Specifies the symbol search path. Separate multiple paths with a 
semicolon (;). If the path contains spaces, it should be enclosed 
in quotation marks. For details, and for other ways to change this 
path, see Symbol Path. 
...