Убрать отладочную информацию Windows DLL?

Question

Я обычно не работаю над разработкой Windows и совершенно не знаком с набором инструментов и системой сборки. Мой встроенный продукт включает в свою файловую систему некоторые библиотеки Windows DLL сторонних производителей (которые используются машиной Windows, которая монтирует файловую систему).

У меня проблема: последний выпуск этих библиотек DLL увеличился в три раза по сравнению с предыдущими сборками, и они больше не помещаются в файловую систему. В функциональности DLL не было много изменений, поэтому я подозреваю, что разработчики просто забыли убрать символы отладки в этом отбрасывании. Я спрошу их, но получение ответа часто занимает дни из-за различий в часовых поясах и языках.

Может ли кто-нибудь объяснить, используя простые шаги для кого-то, кто не знаком с VisualC, как определить, содержит ли DLL-файл отладочную информацию и как ее удалить?

Answer 1

Rebase является частью набора инструментов Microsoft. В дополнение к настройке базового адреса для dll, он может вырезать любую вложенную отладочную информацию в отдельный файл .dbg.

rebase -i 0x10000000 -a -x. \ -P

Теоретически вы должны попытаться определить, строит ли dll уже уникальный базовый адрес, и использовать его. В качестве альтернативы выберите базовый адрес, чтобы минимизировать вероятность столкновения с любыми другими библиотеками, используемыми вашим приложением, чтобы окнам не приходилось исправлять библиотеку DLL при загрузке. В эпоху, когда загрузчики обычно рандомизируют адрес загрузки модулей в качестве функции безопасности, я не уверен, стоит ли больше задавать конкретную настройку базового адреса.

Answer 2

Как правило, сама информация отладки создается в виде отдельного файла *.pdb (база данных программы), а не добавляется в двоичный файл, как в unix. Если разработчики действительно создали отладочную версию библиотеки, более серьезной проблемой может быть проблема зависимостей. Если версия выпуска двоичного файла ссылается на MSVCRT.DLL, то отладочная сборка будет ссылаться на MSVCRTD.DLL (другие библиотеки времени выполнения аналогично называются суффиксом D). Чтобы найти зависимости для конкретного двоичного файла, попробуйте:

dumpbin /imports whatever.dll

Это покажет все зависимости времени выполнения для библиотеки whatever.dll (обратите внимание, что указаны имена библиотек и символы из этих библиотек). Если вы не видите ожидаемый список зависимостей, возможно, существует проблема, которую можно исправить, только если первоначальный разработчик перестроит библиотеку в правильном режиме сборки.

Answer 3

Возможно, вы захотите получить релизные версии от разработчиков, даже если это будет больно, потому что отладочные версии по умолчанию компилируются с отключенной оптимизацией кода. Таким образом, даже если вы как-то удалите отладочную информацию, вы останетесь с кодом, который не так эффективен, как мог бы. (Не говоря уже о любых отладочных сообщениях и сообщениях.)

Что касается определения того, какая у вас DLL, вы можете использовать Dependency Walker , чтобы проверить, связана ли ваша DLL с отладочной или выпускной версией библиотеки времени выполнения VC (при условии, что эти библиотеки не являются статически связаны.)

Answer 4

Средство обхода зависимостей показывает зависимости, но не показывает, была ли удалена отладочная информация. Используйте PeStudio , чтобы увидеть оба.

Answer 5

На данный момент игнорируются другие предложения, такие как получение версии релиза, которая действительна. Инструмент, который разработчики ищут, на самом деле link.exe от Visual Studio (или SDK или WDK).

Если они хотят, чтобы вы могли использовать отладчик вместе с их кодом, они могли бы создавать для вас публичные файлы PDB. Варианты, которые они хотели бы использовать:

  /PDB:filename
  /PDBSTRIPPED:filename

Тем не менее, я боюсь, что вы сами ничего не можете с этим поделать. Сами файлы PDB являются отдельными файлами, и отладочная информация обычно не включается в двоичные файлы на современных компиляторах MS (хотя некоторые компоненты RTTI могут быть включены, не говоря уже об именах файлов и строках для ASSERT и подобных макросы и «функции» - что является наиболее вероятным объяснением воспринимаемого вздутия).

Примечание: binplace.exe из WDK предоставляет те же функциональные возможности, что и вышеперечисленные флаги, но имеет несколько более запутанный (хотя и подходящий для процесса построения WDK) синтаксис.