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

Question

У меня проблема с тем, чтобы 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. Я не вижу имен в управляемых стеках. Что я могу делать не так?

Answer 1

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

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

Answer 2

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

  

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

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

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

Answer 3

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