Oserror winerror 193 1 не является приложением win32
У меня проблема с загрузкой Windows DLL в Ctypes, которая выдает ошибку:
В моем случае это 32-битная DLL, созданная с VS2012 на 64-битной Windows 7, и на моей машине для разработки я могу нормально ее загрузить. Я проверил, что это 32-битный, используя dumpbin /headers :
Проблема возникает, когда я пытаюсь загрузить ту же DLL через Ctypes на производственную виртуальную машину, которая также является 64-битной Windows 7. Что я делаю, это:
Из других вопросов я уже попробовал несколько вещей.
это , этот , этот а также этот Вопрос предполагает, что моя среда должна быть такой же, то есть 32-битный Python, 32-битная DLL. Это касается моей системы разработки и виртуальной машины, на которой я тестирую. В обоих случаях я использую 32-разрядную версию WinPython. Это работает на машине разработчика, это терпит неудачу на VM.
Вот , это связано с g ++ и зависимостью от старых сред выполнения Visual Studio. Я скомпилировал все с VS2012, поэтому я не думаю, что это применимо здесь. Существует отложенная загрузка зависимости от сторонней библиотеки, которая нуждается в MSVCR80.dll , но он загружен с задержкой и никогда не вызывается.
Я также установил 32-разрядную среду выполнения Visual C ++ на целевой машине.
это предполагает, что DLL необходимо экспортировать интерфейс C, что она и делает.
Я знаю, что путь к файлу / имя файла к DLL является правильным, как и раньше, были проблемы с отсутствующими зависимостями DLL, когда я получил всплывающее окно Windows. Это ушло сейчас.
Ошибка очень общая, довольно загадочная. Поскольку он работает на компьютере разработчика в той же среде Python, я предполагаю, что это связано с некоторыми зависимостями, которые может дать мне только установка Visual Studio?
Решение
Запустите под отладчиком, таким как cdb или же windbg , Вызов windll.kernel32.DebugBreak() как раз перед звонком CDLL(dllabspath) , Установить точку останова на kernelbase!LoadLibraryExW и возобновить поток через g , Когда он ломается обратно в отладчик введите pt выполнить до возврата функции. Затем введите !teb проверить LastStatusValue для потока. Это значение статуса NT может помочь.
При отладке это может помочь:
Есть несколько кодов состояния, которые выдают ошибку Win32 ERROR_BAD_EXE_FORMAT (193). В вашем случае это STATUS_INVALID_IMAGE_FORMAT ( 0xC000007B ). Возможно, в рабочей виртуальной машине одна из зависимых библиотек DLL, которую она пытается загрузить, является 64-разрядной. В точке останова введите du poi(@esp+4) напечатать первый аргумент, который является Unicode-путем к DLL, которую он пытается загрузить. Также проверьте трассировку стека через kc ,
Используя этот совет, я обнаружил зависимость от 64-битной библиотеки WinPCAP DLL. Проходя через все с DependencyWalker, он выглядел одинаково на обеих машинах, жалуясь на 64-битную зависимость, но, видимо, на новую машину, путь загрузки DLL был другим и он никогда не мог найти 32-битную версию.
Читайте также: