Хороший способ отладки "неправильная конфигурация приложения" проблемы в системах конечного пользователя?

Question

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

Если я запускаю исполняемый файл локально и получаю сообщение об ошибке Windows, говорящее, что «Не удалось загрузить [что угодно]. Конфигурация приложения неверна«Похоже, это означает, что отсутствует библиотека, от которой зависит все».Но он (довольно раздражительно) не указывает, какую именно DLL он испытывал при загрузке.Иногда я могу решить это с помощью Dependency Walker , чтобы увидеть, есть ли какие-либо библиотеки, которые явно отсутствуют.В других случаях я могу прибегнуть к Process Monitor , который может показать мне, какой файл Windows искал до выдачи сообщения об ошибке.

Но это не те инструменты, которые подходят для конца-пользователь должен использовать, когда пытается диагностировать свою проблему.Есть ли способ убедить Windows точно сказать, какую библиотеку она решает, чтобы ее можно было вывести в журнал или отобразить в окне сообщения?

Answer 1

По моему опыту, частой причиной такого рода ошибок является случайная отправка компонента, который был связан с отладочной версией среды выполнения C, которая явно не распространяется повторно, и поэтому только в системе конечного пользователя, если онислучайно установлена ​​соответствующая версия VisualStudio.Имя будет выглядеть примерно так: MSVCR80D.DLL вместо MSVCR80.DLL.

Dependency Walker, безусловно, является подходящим инструментом для проверки вашего исполняемого файла в качестве разработчика.Он может подключить приложение к событиям загрузки DLL и запустить его, так что вы можете обнаружить библиотеки DLL, которые динамически загружаются во время выполнения, а также библиотеки DLL, которые были названы во время сборки.

Кроме того, программа Dependency Walker поддерживает сценарии, иМожно написать файл журнала.Я использую его таким образом, как часть процесса сборки, чтобы проверить отправку перед упаковкой для выпуска.Я размещаю все файлы, которые должны быть отправлены, в макете их поставляемого дерева каталогов.Я использую режим отладки приложения, находящегося в системе обхода зависимостей, который заставляет его загружать все необязательные фрагменты и затем завершать работу.Depends.exe оставляет мне хороший лог-файл, который я проверяю с помощью сценария Perl и завершаю сборку, если какая-либо DLL была загружена из любой точки системы, кроме \WINDOWS или области подготовки, или если неожиданная версия или отладочная версиясреда выполнения C была загружена.Только после успешной проверки я создаю пакет установщика InnoSetup, который будет выпущен.Это несколько раз избавляло от смущения и стоило того, чтобы понять, как это сделать.

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

Редактировать: Официальный дом Зависимый ходок - хорошее место, чтобы побродить,Предлагаемая версия может быть более новой, чем версия, включенная в MSVS, и имеется достаточное количество достойной документации по расширенному использованию.

Я могу подтвердить, что я запускал IE, профилированный в зависимости от.exe, но не тестировалмного всего.

Answer 2

Один из методов, который я считаю полезным, - это создание проекта установщика в Visual Studio (даже если вы его не отправляете). Внутри вашего решения создайте новый проект установки и развертывания и добавьте в него первичный вывод проекта, а затем соберите установщик. Это выполнит фазу проверки зависимостей dll, которую вы увидите в разделе «Обнаруженные зависимости». Так что если есть какие-либо dll, которые вы пропустили, вы должны увидеть их в этом списке.

Конечно, теперь, когда у вас есть установщик, для установки которого потребовалось всего 5 минут, вы можете его отправить, и он будет также обеспечивать правильную настройку среды выполнения Visual Studio.

Answer 3

Журнал событий Windows обычно содержит некоторую ценную информацию после этих сообщений.

В XP щелкните правой кнопкой мыши «мой компьютер», выберите «управлять» и перейдите в «Просмотр событий», проверьте системный журнал, найдите сообщения об ошибках, которые появляются примерно в то время, когда появилось окно сообщения. Там должно быть несколько из них. один из них будет содержать имя оскорбительной dll.