Проблема с символом при отладке кода C # - PullRequest
Новая
       43

Проблема с символом при отладке кода C #

0 голосов
/ 12 октября 2009

Я использую WinDbg для загрузки аварийного дампа из управляемого кода (C #, консольное приложение, созданное для Любой ЦП ), и аварийный дамп создается на платформе x64. Я отлаживаю на платформе x64. Я поместил соответствующий файл PDB в путь символов.

Но WinDbg всегда находит символ из странной папки. Вот пример (когда я получил от использования! Sym noisy): 

SYMSRV:  c:\MySymbols\FooService.pdb\4311207E2E2D442CB7473828D2488F941\FooService.pdb not found

Мое приложение называется FooService.exe, а связанный файл PDB - FooService.pdb. Я установил C:\MySymbols в качестве пути к символу и скопировал FooService.pdb в каталог C:\MySymbols. Но почему WinDbg не находит FooService.pdb в C:\MySymbols, а находится в странной подпапке «FooService.pdb \ 4311207E2E2D442CB7473828D2488F941»?

В моем сценарии, чтобы загрузить файл символов PDB, каково лучшее решение (я должен вручную создать подпапку FooService.pdb\4311207E2E2D442CB7473828D2488F941 вручную)?

1 Ответ

1 голос
/ 12 октября 2009

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

Вы можете заставить загрузчик символов игнорировать любую кэшированную копию с помощью команды .reload /fo. В сочетании с параметром .sympath вы сможете настроить загрузку. Простой способ добавить свой локальный путь к пути символа - .sympath+ <PATH>. После этого выполните команду .reload /fo, чтобы игнорировать любые ранее кэшированные PDB.

РЕДАКТИРОВАТЬ: Я немного изменил свой ответ, поскольку я считаю, что я изначально неправильно понял ваш вопрос. Надеюсь, это обновление будет более полезным.

...