#windbg #debug-symbols #pdb-files
#windbg #отладочные символы #pdb-файлы
Вопрос:
Анализируя аварийный дамп, WinDbg сообщает, что мои символы (PDB-файл) не соответствуют модулю. Символы — это те, которые были сгенерированы при компиляции библиотеки DLL. Единственное, что, как я могу себе представить, могло вызвать несоответствие, это то, что DLL была подписана.
Я использую !chksym для проверки символов:
!chksym libcef.dll D:symlibcef.dll.pdb
libcef.dll
Timestamp: 5BB3D477
SizeOfImage: 626D000
pdb: F:srcoutlibcef.dll.pdb
pdb sig: B0065D83-113F-63BE-53BC-AEF07EC816B4
age: 1
libcef.dll.pdb
pdb sig: 9BA88A40-D168-44F2-44C1-DD2D73A38B38
age: 1
sig MISMATCH: libcef.dll.pdb and libcef.dll
Комментарии:
1. Под подписью вы подразумеваете подписание Authenticode? Я не знаю, что это изменяет заголовок debug. Больше похоже, что вы перекомпилировали dll из тех же источников. Вы можете принудительно загрузить с помощью .reload -f -i libcef.dll если ваш символьный путь содержит каталог, в котором находится ваш новый pdb. Используйте .sympath F:srcout чтобы добавить его. Тогда отладка не должна быть проблемой.
2. @AloisKraus Да, подпись authenticode. Принудительная перезагрузка, похоже, работает нормально. Меня больше беспокоит, могу ли я отлаживать неправильные материалы из-за несоответствия символов. Скажите, пожалуйста, как я могу посмотреть заголовок debug?
3. Я заметил, что к вашему pdb добавлен файл .dll afaik vc создает pdb с . удаленная dll, т.Е. создается libcef.pdb вместо libcef.dll.pdb передан ли вам переключатель -Fxyz, который предоставляет другое имя для pdb в ваших проектах? отсутствие подписи afaik ничего не меняет внутри вашего двоичного файла (представьте, что ms внедряет бэкдор oops, если он это делает, не так ли? ) используйте dumpbin /headers для проверки пути, встроенного в двоичный файл
Ответ №1:
Подписание кода исполняемым файлом или DLL не влияет на заголовок debug исполняемого файла. Таким образом, он все равно будет соответствовать PDB.
...SigningPdbbinRelease>symchk signed.exe /s .
SYMCHK: FAILED files = 0
SYMCHK: PASSED IGNORED files = 1
...SigningPdbbinRelease>symchk unsigned.exe /s .
SYMCHK: FAILED files = 0
SYMCHK: PASSED IGNORED files = 1
И
...SigningPdbbinRelease>ChkMatch.exe -c signed.exe SigningPdb.pdb
ChkMatch - version 1.0
Copyright (C) 2004 Oleg Starodumov
http://www.debuginfo.com/
Executable: signed.exe
Debug info file: SigningPdb.pdb
Executable:
TimeDateStamp: bc78c18e
Debug info: 2 ( CodeView )
TimeStamp: a7b373e5 Characteristics: 0 MajorVer: 0 MinorVer: 0
Size: 97 RVA: 000026a0 FileOffset: 000008a0
CodeView format: RSDS
Signature: {b8ed520c-cdfc-486b-8e1a-7c0752a2a41f} Age: 1
PdbFile: ...ReleaseSigningPdb.pdb
Debug info: 16 ( Unknown )
TimeStamp: 00000000 Characteristics: 0 MajorVer: 0 MinorVer: 0
Size: 0 RVA: 00000000 FileOffset: 00000000
Debug information file:
Format: PDB 7.00
Signature: {b8ed520c-cdfc-486b-8e1a-7c0752a2a41f} Age: 1
Result: Matched
Временная метка находится в заголовке COFF. Этот заголовок имеет размер всего 24 байта и не изменится во время подписания кода.
Большинство изменений произойдет в новом разделе для сертификатов. Однако этот раздел также будет проигнорирован во время подписания кода. В противном случае вторая подпись уничтожила бы первую подпись. (Кстати: этот раздел использовался для переноса вредоносного кода внутрь подписанного исполняемого файла)
Конечно, «обычные» контрольные суммы, которые не учитывают структуру файла EXE / DLL, выдадут другую контрольную сумму.
Что могло случиться с вашей DLL или EXE?
- вы случайно перестроили его, поэтому временная метка вашей DLL больше не соответствует PDB
- вы используете аспектно-ориентированное программирование (AOP) в .NET, и после перестройки происходит некоторое переплетение кода. Эти инструменты могут быть не в состоянии перестроить PDB после ткачества, поэтому несоответствие PDB уже существует до того, как DLL подписана кодом.