WinDBG не отображает исходные строки, несмотря на загрузку приватных файлов pdb - PullRequest
5 голосов
/ 21 мая 2011

Я пытаюсь отладить проблему в нативной DLL с помощью WinDBG.Я считаю, что у меня загружены закрытые символы, но WinDBG не отображает строки источника или информацию о параметрах.Вот что я наблюдаю;любая помощь будет принята с благодарностью!

У меня есть PDB, который, я считаю, соответствует DLL в пути поиска символов.Запуск lm Я вижу:

01050000 01058000   3NMSMTHR C (private pdb symbols)  e:\ads_symbols\3NMSMTHR.pdb

Поскольку это говорит о "частных символах pdb", я ожидаю, что это приватный pdb.

Я также запустил symchk и вижуследующий вывод:

C:\utils\inetmgr\patch01>"c:\Program Files\Debugging Tools for Windows (x86)\symchk.exe" /v 3nmsmthr.dll /s c:\utils\inetmgr\patch01
[SYMCHK] Searching for symbols to C:\utils\inetmgr\patch01\3nmsmthr.dll in path c:\utils\inetmgr\patch01
DBGHELP: Symbol Search Path: c:\utils\inetmgr\patch01
[SYMCHK] Using search path "c:\utils\inetmgr\patch01"
DBGHELP: No header for C:\utils\inetmgr\patch01\3NMSMTHR.DLL.  Searching for image on disk
DBGHELP: C:\utils\inetmgr\patch01\3NMSMTHR.DLL - OK
DBGHELP: 3NMSMTHR - private symbols & lines
     c:\utils\inetmgr\patch01\3NMSMTHR.pdb
[SYMCHK] MODULE64 Info ----------------------
[SYMCHK] Struct size: 1680 bytes
[SYMCHK] Base: 0x10000000
[SYMCHK] Image size: 32768 bytes
[SYMCHK] Date: 0x4cc1b0f8
[SYMCHK] Checksum: 0x00000000
[SYMCHK] NumSyms: 0
[SYMCHK] SymType: SymPDB
[SYMCHK] ModName: 3NMSMTHR
[SYMCHK] ImageName: C:\utils\inetmgr\patch01\3NMSMTHR.DLL
[SYMCHK] LoadedImage: C:\utils\inetmgr\patch01\3NMSMTHR.DLL
[SYMCHK] PDB: "c:\utils\inetmgr\patch01\3NMSMTHR.pdb"
[SYMCHK] CV: RSDS
[SYMCHK] CV DWORD: 0x53445352
[SYMCHK] CV Data:  I:\usr\bpi\adrutl\3NMSMTHR.pdb
[SYMCHK] PDB Sig:  0
[SYMCHK] PDB7 Sig: {A865C40A-5070-4752-AD1F-CD3087843807}
[SYMCHK] Age: 4
[SYMCHK] PDB Matched:  TRUE
[SYMCHK] DBG Matched:  TRUE
[SYMCHK] Line nubmers: TRUE
[SYMCHK] Global syms:  TRUE
[SYMCHK] Type Info:    TRUE
[SYMCHK] ------------------------------------
SymbolCheckVersion  0x00000002
Result              0x001f0001
DbgFilename
DbgTimeDateStamp    0x4cc1b0f8
DbgSizeOfImage      0x00008000
DbgChecksum         0x00000000
PdbFilename         c:\utils\inetmgr\patch01\3NMSMTHR.pdb
PdbSignature        {A865C40A-5070-4752-AD1F-CD3087843807}
PdbDbiAge           0x00000004
[SYMCHK] [ 0x00000000 - 0x001f0001 ] Checked "C:\utils\inetmgr\patch01\3NMSMTHR.DLL"

SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1

Это находит PDB по указанному мной правильному пути (обратите внимание, что я скопировал этот точный файл PDB в e: \ ads_symbols, который является путем, видимым в выводе lm).Этот вывод symchk сообщает о номерах строк: true, и поэтому я ожидаю увидеть информацию о частном стиле.Однако, если я запускаю ~ kv , то для моих функций в трассировке стека я вижу:

00bef2ac 01052a8a 00000000 00000000 00020aa4 3NMSMTHR!BPMThrProcTerm+0x2c0
00bef2cc 100073eb 00bef4d8 00000000 00000000 3NMSMTHR!BPMThrThreadInitName+0x2a

И это не похоже на чтение личной информации - я неполучить список источников, как я, для функций MS CRT, которые имеют частные символы на сервере символов MSFT.Также, если я сделаю x / t / d 3NMSMTHR! ThreadInitName , тогда я получу

01052a60 <NoType> 3NMSMTHR!BPMThrThreadInitName = <no type information>

И, наконец, если я попытаюсь использовать .frame3 (чтобы перейти к этому кадру), а затем выполнить DV , чтобы отобразить местных жителей, я получаю:

0:001> .frame
03 00bef2cc 100073eb 3NMSMTHR!BPMThrThreadInitName+0x2a
0:001> dv
Unable to enumerate locals, HRESULT 0x80004005
Private symbols (symbols.pri) are required for locals.
Type ".hh dbgerr005" for details.

Это не имеет смысла для меня.Любая помощь приветствуется.Моя общая цель - получить информацию о параметрах и источниках.ИЛИ, чтобы подтвердить, что файл PDB, который у меня есть, на самом деле НЕ является частными символами.Я не создавал эту DLL или PDB, и при этом я не знаю каких-либо особенностей передаваемых ей параметров компоновщика.

Спасибо!

РЕДАКТИРОВАТЬ:

Я не упомянул, что получаю ошибку контрольной суммы:

*** WARNING: Unable to verify checksum for C:\utils\inetmgr\3NMSMTHR.dll

Извините!Я пытался выполнить команду .lines , как указано ниже, и я вижу:

*** WARNING: Unable to verify checksum for C:\utils\inetmgr\3NMSMTHR.dll
DBGHELP: 3NMSMTHR - private symbols & lines 
    e:\ads_symbols\3NMSMTHR.pdb
Line number information will not be loaded

Так что я думаю, что это моя проблема.Что приводит к моему следующему вопросу: есть ли способ исправить контрольную сумму (которая указана как 0, см. Выше вывод symchk)?Этот PDB является правильным с учетом вывода symchk.Могу ли я сделать так, чтобы он обошел проверку контрольной суммы?

EDIT2:

Для всех, кто сталкивался с этим: я смог исправить предупреждение о контрольной сумме с помощью:

editbin /release 3NMSMTHR.DLL

Это устанавливает контрольную сумму в заголовке PE.Затем мне пришлось запустить

.symopt+0x40

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

Это исправило предупреждение о контрольной сумме ... но ЕЩЕ не было информации о параметрах (запуск dv в правом кадре), нет информации об исходной строке и т. д.

Так что теперь я потерялся.Возможно ли, что эти PDB не содержат эту информацию?Как я могу это подтвердить?Как бы я построил их, чтобы содержать это?Для их создания мы используем NMAKE.

EDIT3:

Я перестроил DLL и PDB как DEBUG, а затем получил всю ожидаемую информацию о трассировке стека.Итак, теперь мой вопрос: (1) можно ли встроить релиз и получить статические функции, информацию о параметрах и т. Д. (Информация о частных символах)?и (2) трассировка стека, которую я получал с выпуском dlls + pdbs, была неправильной - первая точка входа в функцию была правильной, но затем следующий кадр стека показал функцию, которая не была вызвана.Я предполагаю, что релизная DLL включала некоторые функции, и каким-то образом PDB просто «угадывал» функцию в этом кадре?Очень странно.

Ответы [ 4 ]

4 голосов
/ 21 мая 2011

Вы пробовали команду .lines?

2 голосов
/ 03 июля 2012

Если вы хотите иметь возможность разбирать дампы или трассировки стека даже в режиме Release, вы должны убедиться в следующем:

  1. Вы компилируете с / Zi или / ZI (формат отладочной информацииодин из двух вариантов базы данных программы).
  2. Вы не компилируете с / Oy (указатели пропуска кадров).
  3. Вы связываете с / DEBUG (Создать информацию отладки).
  4. Вы сохраняете (но не распространяете) полученный файл .pdb.

Главное, чтобы не пропустить указатели фреймов;пропуск их экономит немного времени / пространства при вызове функции, но делает очень сложным проход по стеку.Обратите внимание, что вы все еще можете получить нечетные следы стека из сборок релиза из-за других настроек оптимизации (особенно встраивания), но они все равно должны иметь большинство интересных функций.

2 голосов
/ 21 мая 2011

У вас не будет информации о типе, если функция написана на ассемблере.Также возможно, что статическая библиотека была связана с DLL, и статическая библиотека не имела полной отладочной информации.

0 голосов
/ 02 мая 2018

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

...