C ++: наш установщик отказывается загружать библиотеку ресурсов нашего приложения (модуль не найден) [только для XP]

Question

В основном, когда наше программное обеспечение работает под Windows 7, оно работает: вызов на LoadLibrary() успешен, и жизнь хороша.

Но когда то же программное обеспечение запускается на коробке XP (последние исправления), вызов LoadLibrary завершается неудачно, возвращая NULL с кодом ошибки, который задает module not found.

Я пытался заставить его использовать UNICODE версию LoadLibraryW вместо версии LoadLibraryA для нашего приложения.

Я попытался убедиться, что папки установки отображаются через букву локального диска.

И я проверил, что путь действительно доступен с исполняющей машины (т. Е. Сгенерированная ошибка указывает, какой путь он пытается загрузить, и я использую эту строку для фактического поиска файла).

Странно то, что этот код работает правильно при компиляции на VS 2008 SP2.

Он также отлично работает, когда клиентский компьютер Windows 7.

Сбой только в том случае, если он скомпилирован + связан с помощью VS 2010 и запущен на клиенте XP.

Я в полной растерянности относительно того, что в мире может пойти не так.

Чтобы добавить странности в рагу:

Если я включу свой XP VM на своем компьютере для разработки и запусту этот код в отладочной сборке VS2010 в XP,это работает правильно!

На самом деле, под моим XP VM стандартная (релизная) сборка также работает правильно !!!

Это просто при запуске из настоящего XP окна, что он выходит из строя (я уже пробовал пару XP машин, оба полностью исправлены).

Есть мысли?!
У меня заканчиваются заслуживающие доверия идеи.:(

Answer 1

Я бы проанализировал различия между вашим набором инструментов и комбинациями платформ.

Например, различие между VS2008 и VS2010 менее важно, чем то, какой SDK вы используете. Разные SDK могут быть нацелены на разные библиотеки времени выполнения msvc.

Возможно ли, что на вашей виртуальной машине XP установлена ​​библиотека времени выполнения VS2010, а не другая платформа XP?

Вы также можете попробовать утилиту «зависимость» на нерабочей платформе для определения отсутствующих зависимостей.

Answer 2

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

Недавно я только что прошел через эту проблему в моем собственном проекте.Я даже попытался указать полный путь к файлу в LoadLibraryA, и он вернул этот код ошибки.Проблема заключалась в том, что LoadLibrary пытался найти зависимые DLL от DLL, которую я загружал.Поэтому, возможно, у вашей библиотеки DLL ресурсов есть некоторые библиотеки DLL, к которым LoadLibrary не знает, как добраться.

Answer 3

Другая распространенная проблема - при загрузке «a.dll», которая зависит от «b.dll».Если есть проблема с "b.dll", вы иногда получаете ошибку, указывающую, что он не может загрузить "a.dll".Что верно, но не полезно.

Есть несколько приложений, которые могут сообщить вам зависимости DLL.