WinDbg отсутствует символы для управляемого кода - PullRequest
Новая
       6

WinDbg отсутствует символы для управляемого кода

2 голосов
/ 10 сентября 2009

У меня проблема с тем, чтобы WinDbg использовал файлы PDB для моих файлов .NET DLL. Дамп зависания, на который я смотрю, из рабочей сборки, но у меня есть файлы PDB из отладочной сборки того же кода.

Я установил путь к символам, чтобы включить локальную папку и сервер символов Microsoft. 

C:\websymbols\foo;srv*c:\websymbols*http://msdl.microsoft.com/download/symbols

Я поместил все мои файлы PDB в C:\websymbols\foo. Тем не менее, списки управляемого стека не содержат имен методов.

Выполнение перезагрузки, .reload /f, говорит мне: 

DBGHELP: No debug info for FOO.dll.  Searching for dbg file
SYMSRV:  c:\websymbols\foo\FOO.dbg\49B7F17C10000\FOO.dbg not found
SYMSRV:  c:\websymbols\FOO.dbg\49B7F17C10000\FOO.dbg not found
SYMSRV:  http://msdl.microsoft.com/download/symbols/FOO.dbg/49B7F17C10000/FOO.dbg not found
DBGHELP: .\FOO.dbg - file not found
DBGHELP: .\dll\FOO.dbg - path not found
DBGHELP: .\symbols\dll\FOO.dbg - path not found
DBGHELP: FOO.dll missing debug info.  Searching for pdb anyway
DBGHELP: Can't use symbol server for FOO.pdb - no header information available
DBGHELP: FOO.pdb - file not found
*** WARNING: Unable to verify checksum for FOO.dll
*** ERROR: Module load completed but symbols could not be loaded for FOO.dll
DBGHELP: FOO - no symbols loaded

При подключении WinDbg к сервису в тестовой среде управляемые стеки хорошо отображаются с именами методов. Выгрузка памяти и локальный анализ файла DMP. Я не вижу имен в управляемых стеках. Что я могу делать не так?

Ответы [ 3 ]

7 голосов
/ 10 сентября 2009

Вам нужны точно такие же файлы PDB. Символы отладки не будут работать с розничным дампом. И вам нужен файл PDB точно такой же сборки.

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

3 голосов
/ 10 сентября 2009

Сейчас мало что можно с этим поделать. Как говорит Джон Роббинс :

Самое главное все разработчики должны знать: файлы PDB так же важно, как исходный код! ... я был в бесчисленных компаниях, чтобы помочь они отлаживают те ошибки стоимостью в сотни тысяч долларов, и никто не может найти файлы PDB для сборки работает на производственном сервере. Без соответствующих файлов PDB вы только что сделал вашу задачу отладки почти невозможно.

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

[edit:] Извините, только что заметил, что вы используете WinDBG. В этом случае, как говорит Ремус, .reload / f / i может достичь того же трюка (с теми же рисками).

1 голос
/ 11 сентября 2009

ОК, я задал не тот вопрос. Мне даже не нужны символы для кода .NET (как указал Ремус). Так что это не ответ на мой вопрос, но это решение моей проблемы, которое, похоже, связано со сборкой .NET на компьютере, на котором работает WinDbg.

Я получаю значимую информацию о стеке, когда .chain сообщает мне: 

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos: image 2.0.50727.**1433**, API 1.0.0, built Tue Oct 23 20:41:30 2007

(То же, что и на сервере, на котором был получен дамп).

Я не получаю никакой информации, кроме адресов от !clrstack, когда запускаюсь на машинах, где .chain говорит мне: 

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos: image 2.0.50727.**3053**, API 1.0.0, built Fri Jul 25 07:08:38 2008
...