У меня есть файл mindmp из-за сбоя целевого приложения. Могу ли я пересобрать файлы dll / pdb для версии программного обеспечения и правильно отображать символы загрузки windbg?
Моя проблема в том, что наши файлы pdb хранятся только для основных выпусков (к сожалению). Это ежедневная сборка, которую я могу перестроить самостоятельно, но я спотыкаюсь из-за ошибок.
С! Sym шумит на: «Заголовок изображения не соответствует заголовку изображения в памяти».
DBGENG: C:\...\XXX.dll image header does not match memory image header.
DBGENG: XXX.dll - Partial symbol image load missing image info
DBGHELP: Module is not fully loaded into memory.
DBGHELP: Searching for symbols using debugger-provided data.
DBGHELP: C:\...\XXX.pdb - mismatched pdb
Обратите внимание, что я создал pdb с dll, они из того же каталога RELEASE (должен ли я создавать отладку?)
Тезисы представляют собой сборки выпуска (поскольку сборки выпуска устанавливаются на цель и вылетают из строя), следует ли мне каким-то образом использовать библиотеки DLL отладочной сборки, чтобы получить больше информации о символах?





По моему опыту, наверное, нет.
Если у вас есть точный каталог сборки и сборка с настройками компилятора точно так же, это может сработать. Вы определенно не сможете загружать символы из отладочной сборки в аварийный дамп релиза.
Вам нужно будет включить опцию «загружать что угодно»: .symopt + 0x40, чтобы программа windbg игнорировала различия в отметках времени.
Утилита ChkMatch разработана именно для этого сценария. Пока у вас есть исходный .EXE, вы можете перекомпилировать исходники (с теми же настройками компилятора и компилятора) и исправить новый .PDB, чтобы он соответствовал старому .EXE.
В этом примере OriginalExecutable.exe - это исполняемый файл, у которого больше нет файла .PDB, а RebuiltPDB.pdb - это тот, который был создан путем восстановления исходного исходного кода.
chkmatch -m OriginalExecutable.exe RebuiltPDB.pdb
Теперь, когда два файла имеют свои оригинальные имена, отладчик должен принять их как совпадающую пару.
Файлы PDB привязаны к своим EXE-файлам с помощью идентификатора GUID и «возраста» (это порядковый номер). Они встроены в EXE и PDB. GUID восстанавливается при каждой полной сборке, а «возраст» изменяется при каждой инкрементной сборке.
Отладчик использует их, чтобы убедиться, что он ищет правильный PDB для EXE-файла.
Я не знал об инструменте "chkmatch", упомянутом SteveMan, но подозреваю, что он работает, исправляя GUID / возраст, чтобы они совпадали.
если у вас все еще есть точный исходный код, из которого был скомпилирован образ, перестройте его, создав новый файл pdb, а затем проинструктируйте WinDbg принудительно загрузить этот pdb при открытии аварийного дампа - однажды в моей практике это сработало.
Слишком поздно, чтобы помочь Дугу, но ради всех, кто сталкивается с этим вопросом, другой поток (Можно ли загрузить несовпадающие символы в Visual Studio?) указал способ заставить WinDbg принимать несовпадающие файлы .PDB
.symopt_0x40
Это .symopt + 0x40