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

Один из вариантов - оставить файлы символов на месте (то есть в выходной папке сборки), а затем использовать параметр командной строки -у 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. 

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

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

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

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

Вы видите:

MyDll!AClass::AFunction+SomeHexAddress

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

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

В процессе сборки мы копируем частные файлы 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.

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

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

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

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

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

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

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

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, прежде чем пытаться использовать кеш сервера символов.

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

Как оказалось, моя целевая машина, подготовленная внутри Visual Studio, не получила последнюю сборку при развертывании на ней, поэтому возникла ошибка «driver.sys имеет несоответствующие символы».

По сути, развертывание не заменило драйвер его модифицированной версией для меня. Используйте инструмент devcon, чтобы правильно установить его, и Windbg снова будет счастлив.