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

Question

У меня возникла проблема с получением WinDbg для использования файлов PDB для файлов DLL .NET. Висячий дамп, на который я смотрю, является производственной сборкой, но у меня есть файлы 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

Там не много вы можете сделать о нем Теперь. Как Джон Роббинс says:

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

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

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

Answer 3

ОК, я задал неправильный вопрос. Мне даже не нужны символы для кода .NET (как заметил Ремус). Так что это не ответ на мой вопрос, но это решение моей проблемы, которая, похоже, связана с .NET build на машине, на которой работает 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