Модуль LoadLibrary не найден - DLL ад после установки Office 2007

Question

К сожалению, это будет довольно открытый вопрос, но я нахожусь в тупике, и я подумал, что хотел бы обратиться за советом.

Это приложение Visual C ++ MFC, использующее Visual Studio 2008 с пакетом обновления 1 (SP1).

У нас с коллегами был установлен Office 2007, и с тех пор у нас были странные проблемы с загрузкой DLL в нашем приложении.В частности, LoadLibrary не может загрузить одну из наших библиотек DLL (первую, которую он загружает) и возвращает код ошибки 126 (модуль не найден).Что действительно странно, так это то, что если я просто запускаю исполняемый файл из проводника Windows, он работает нормально.

Я предпринял обычные шаги для диагностики проблем:

1. Убедитесь, что файл существует и на него указывает текущий рабочий каталог.
2. Запустите средство обхода зависимостейи убедитесь, что его зависимости загружаются правильно.Они все загружаются нормально, кроме тех, которые этот вопрос говорит, что все в порядке, чтобы потерпеть неудачу.
3. Поэкспериментируйте с загрузкой нескольких разных DLL в одном месте кода.Некоторые из простых «заглушек» dll преуспевают, но большинство из них терпят неудачу.
4. Поэкспериментируйте с загрузкой библиотек DLL, которые выходят из строя из отдельных тестовых приложений - в пустом консольном приложении и голом приложении MFC все библиотеки DLLзагрузка прекрасна!
5. Попытайтесь загрузить библиотеки DLL с помощью LoadLibraryEx и флага LOAD_LIBRARY_AS_DATAFILE, который успешно выполняется, но не дает нам слишком далеко, за исключением того, что указывает, что это, вероятно, проблема зависимости.* Я действительно не знаю, что еще делать на этом этапе.Как я уже сказал, Office 2007 - общая проблема в нашей проблеме, но я не знаю, какие проблемы он может создать.Я действительно даже не знаю, какие шаги предпринять дальше.Есть идеи?

   edit: Я почти уверен, что текущий рабочий каталог по какой-то причине отсутствует в пути к DLL.Кажется, библиотеки DLL, которые терпят неудачу, являются теми, которые нуждаются в любых других библиотеках DLL.Если я включаю вывод отладки Loader Snaps, то текущий рабочий каталог, по-видимому, не находится в пути загрузки DLL.Любая идея, что может вызвать это?

   edit2: Текущая сборка сбросила исполняемый файл в каталог, отличный от рабочего каталога.По какой-то причине, когда я пытался загрузить DLL, которая затем пыталась загрузить ДРУГУЮ DLL, текущий рабочий каталог больше не ищется.Поместив исполняемый файл в каталог со всеми DLL, которые я пытаюсь загрузить, проблемы исчезают.Исходя из всего этого и выводов загрузчиков, я на 98% уверен, что это какая-то странная ошибка Visual Studio, и мне просто придется ее обойти.

Answer 1

Office 2007 включает SafeDllSearchMode в реестре.

http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx

С SafeDlLSearchMode текущий каталог больше не ищется.Чтобы отключить его, они утверждают, что вы можете зайти в regedit и установить для HKLM / System / CurrentControlSet / Control / SessionManager / SafeDllSearchMode значение 0, но у меня это не сработало.Вызов SetDllDirectory для текущего каталога DID работает для меня, хотя это работает, только если вы ориентируетесь на XP SP1 +.

Причина, по которой это вызвало проблемы в моем конкретном приложении, заключается в том, что при запуске исполняемого файла из отладчика мы сохраняемисполняемый файл в другом каталоге, чем текущий каталог со всеми другими файлами сборки.Когда мы запускаем вне Visual Studio, мы сначала копируем исполняемый файл в каталог со всеми другими DLL.Каталог, из которого вызывается исходный исполняемый файл, ВСЕГДА находится в пути поиска, поэтому, если вы сохраните свой исполняемый файл и свои библиотеки вместе, вы никогда не столкнетесь с этой проблемой.

Тем не менее, для Microsoft довольно сложно изменитьпуть поиска DLL под нами, как это.

Answer 2

Имеет ли DLL, которая выходит из строя, MSVCRT80 в зависимостях?Если да, наиболее вероятная причина заключается в том, что Office 2007 переопределил MSVCR80.dll