Отладочная информация Windows DLL?
Я обычно не работаю над разработкой Windows и совершенно не знаком с системой toolchain и build. Мой встроенный продукт включает некоторые DLL-библиотеки Windows от третьей стороны в своей файловой системе (которые используются машиной Windows, которая монтирует файловую систему).
У меня проблема: самый последний выпуск этих DLL утроился по сравнению с предыдущими сборками, и они больше не вписываются в файловую систему. Там не было много изменений в функциональность DLL, поэтому я подозреваю, что разработчики просто забыли удалить символы отладки в этом падении. Я спрошу их, но получение ответа часто занимает дни из-за часового пояса и языковых различий.
может ли кто-нибудь объяснить, используя простые шаги для кого-то, незнакомого с VisualC, как определить, содержит ли DLL все еще отладочную информацию и как ее удалить?
5 ответов
вы захотите получить версии выпуска от разработчиков, даже если это больно, потому что отладочные версии по умолчанию скомпилированы с отключенной оптимизацией кода. Поэтому, даже если вы каким-то образом удалили отладочную информацию, вы останетесь с кодом, который не так эффективен, как мог бы быть. (Не говоря уже о том, что там могут быть отладочные ловушки и сообщения.)
Что касается определения того, какая DLL у вас есть, вы можете использовать Зависимость Walker чтобы увидеть, если ваша DLL связана с отладочной или выпускной версией библиотеки времени выполнения VC (при условии, что эти библиотеки не связаны статически.)
как правило, сама отладочная информация построена как отдельная *.pdb
файл (база данных программы) вместо добавления в двоичный файл, как в unix. Если разработчики действительно создали отладочную версию библиотеки,более серьезной проблемой могут быть зависимости. Если версия выпуска двоичной ссылки на MSVCRT.DLL
, тогда сборка отладки будет ссылаться на MSVCRTD.DLL
(другие библиотеки среды выполнения аналогично названы с суффиксом D). Чтобы найти зависимости для конкретного двоичного файла, попробуйте:
dumpbin /imports whatever.dll
Это покажет все зависимости времени выполнения для библиотеки whatever.dll
(обратите внимание, что перечислены имена библиотек и символы из этих библиотек). Если вы не видите список ожидаемых зависимостей, вероятно, существует проблема, которую можно устранить, только если исходный разработчик перестроит библиотеку в надлежащем режиме сборки.
Rebase является частью набора инструментов microsoft. В дополнение к настройке базового адреса для DLL он может удалить любую прикрепленную отладочную информацию в отдельный .dbg-файлы.
rebase-i 0x10000000-a-x .\ - p
теоретически вы должны попытаться определить, уже ли dll строится на уникальный базовый адрес и использовать его. Альтернативно, выберите базовый адрес, чтобы свести к минимуму вероятность столкновения с любыми другими библиотеками DLL, используемыми вашим приложением, чтобы windows не пришлось исправьте dll при загрузке. В эпоху, когда загрузчики обычно рандомизируют адрес загрузки модулей в качестве функции безопасности, я не уверен, что его стоит беспокоиться о конкретной настройке базового адреса.
Dependency walker показывает зависимости, но не показывает, была ли отладочная информация удалена. Использовать PeStudio чтобы увидеть оба.
игнорируя на данный момент другие предложения, такие как получение версии, которая действует. Инструмент, который разработчики будут искать на самом деле link.exe
из Visual Studio (или SDK или WDK).
если они хотели бы, чтобы вы могли использовать отладчик вместе со своим кодом, они могли бы создавать общедоступные файлы PDB для вас. Параметры, которые они хотели бы использовать:
/PDB:filename
/PDBSTRIPPED:filename
однако, боюсь, что вы сами ничего не можете с этим поделать. PDB-файл сами являются отдельными файлами и отладочная информация обычно не включается в двоичные файлы на современных компиляторах MS (хотя некоторые вещи RTTI могут быть включены, не говоря уже об именах файлов и строках для ASSERT
и аналогичные макросы и" функции " - что является наиболее вероятным объяснением воспринимаемого раздувания).
Примечание: binplace.exe
из WDK предоставляет ту же функциональность, что и вышеупомянутые флаги, но имеет несколько более запутанный (хотя и подходящий для сборки WDK процесс) синтаксис.