Ошибка LoadLibrary: исключение первого шанса 0xC0000139 (DLL не найдена) - как отлаживать?

У меня есть dll mytest.dll, которая при загрузке через LoadLibrary() возвращает NULL (и 127 как GetLastError()). Если я использую DependencyWalker для «mytest.dll», он сообщает, что должен загружаться правильно и что все библиотеки DLL найдены правильно. Запуск опции профилировщика DependencyWalker на хосте exe дает мне этот соответствующий раздел в журнале:

00:00:55.099: Loaded "mytest.DLL" at address 0x07860000 by thread 0xBBC.  Successfully hooked module.
00:00:55.115: First chance exception 0xC0000139 (DLL Not Found) occurred in "NTDLL.DLL" at address 0x76E24285 by thread 0xBBC.
00:00:55.115: Unloaded "mytest.DLL" at address 0x07860000 by thread 0xBBC.
00:00:55.115: LoadLibraryW("mytest.dll") returned NULL by thread 0xBBC. Error: The specified procedure could not be found (127).

Есть ли способ отладить это, чтобы узнать, что пытается найти сообщение DLL Not Found, которое сообщает NTDLL.DLL? Или мне следует искать источник проблемы в другом месте?

Обратите внимание, что загрузка той же «mytest.DLL» из другого приложения, похоже, работает правильно.


c++ exception dll loadlibrary
person PeteVasi    schedule 27.04.2009    source источник
comment
Помог ли какой-либо из наших ответов решить эту проблему?   -  person RichieHindle    schedule 03.05.2009

Ответы (3)


arrow_upward
3
arrow_downward

Может ли ваше приложение пытаться вызвать определенную функцию DLL через GetProcAddress после начальной загрузки (возможно), которая не найдена? Это 32-битное или 64-битное приложение?

Если он правильно загружается в другом приложении, как вы предлагаете, то, вероятно, у него правильная точка входа.

Быстрый поиск Google предполагает, что код ошибки, который вы получаете, скорее всего, связан с отсутствующим именем функции (или порядковым значением конкретной функции) в DLL. Я предлагаю открыть DLL в чем-то вроде Exescope и проверить список экспорта.

Это также может объяснить, почему DLL работает с другим приложением (возможно, другое приложение использует другие экспортируемые функции в DLL)?

person RobS    schedule 27.04.2009
comment
Exescope очень помогла в этом разобраться. Оказывается, другое приложение (и его DLL) были скомпилированы с другим компилятором и, следовательно, с другими соглашениями об именах. Сообщение DLL Not Found, по-видимому, было подделкой. - person PeteVasi; 12.06.2009

arrow_upward
3
arrow_downward

Использование Process Monitor или FileMon из SysInternals может дать вам ключ к разгадке, действительно ли myTest.dll просто не там, где его ищут.

person Michael Burr    schedule 27.04.2009

arrow_upward
2
arrow_downward

DependencyWalker показывает неявные зависимости (зависимости, которые автоматически обрабатываются загрузчиком Windows). Библиотеки DLL, которые вы загружаете с помощью LoadLibrary, являются явными зависимостями, и DependencyWalker не может их найти (например, имена библиотек могут быть прочитаны из файла ini, и DependencyWalker никак не может это сделать).

Нет ничего необычного в том, что DLL работает в одном приложении, а не в другом. В наиболее распространенном сценарии одно приложение уже имеет загруженную необходимую dll, а другое - нет. Если dll отсутствует на пути, ваша dll будет работать в первом случае, а не во втором.

В любом случае, воспользуйтесь предложением Майкла Берра и используйте FileMon. Несмотря на то, что на веб-сайте SysInternals говорится, что FileMon устарел, его все же намного проще использовать, чем ProcMon.

person jdigital    schedule 27.04.2009