Error Loading Dll in Python, Not a Valid Win32 Application

Error loading DLL in python, not a valid win32 application

As the comments suggest, it could be an architecture problem.

If you're using a 32bit DLL with 64bit Python, or vice-versa, then you'll probably get errors.

Since I've had your error before, I recommend trying to load your DLL with 32bit Python.

One way to test if a *.dll-file is 32bit or 64bit, is to use dumpbin.exe, e.g.

dumpbin /headers dsusb.dll

...

FILE HEADER VALUES
             14C machine (x86)
...

machine (x86) means 32bit, machine (x64) means 64bit.

ImportError: DLL load failed: %1 is not a valid Win32 application. But the DLL's are there

Unofficial Windows Binaries for Python Extension Packages

You can find any Python libraries from here.

ImportError: DLL load failed: %1 is not a valid Win32 application - scikit-learn+

I was able to fix it.

The way to go was 'force-reinstall'.

This was enough to get scikit-learn up and running.

pip install --upgrade --force-reinstall scipy

Ctypes throws WindowsError: [Error 193] %1 is not a valid Win32 application, but it's not a 32/64-bit issue

@eryksun commented:

Run under a debugger such as cdb or windbg. Call windll.kernel32.DebugBreak() just before calling CDLL(dllabspath). Set a breakpoint on kernelbase!LoadLibraryExW and resume the thread via g. When it breaks back into the debugger enter pt to execute up to the function return. Then enter !teb to check the LastStatusValue for the thread. This NT status value may be of more help.

Further:

If you prefer to keep the system as clean as possible, try the following: windll.kernelbase.LoadLibraryExW(c_wchar_p(dllabspath), None, 0); status = windll.ntdll.RtlGetLastNtStatus().

Otherwise it requires installing the debugging tools from the SDK. Symbols can be downloaded on demand from Microsoft's symbol server by setting the environment variable _NT_SYMBOL_PATH=symsrv*symsrv.dll*C:\Symbols*http://msdl.microsoft.com/download/symbols, which caches symbols in C:\Symbols

When debugging, this may help:

There are several status codes that produce Win32 error ERROR_BAD_EXE_FORMAT (193). In your case it's STATUS_INVALID_IMAGE_FORMAT (0xC000007B). Possibly in the production VM one of the dependent DLLs that it tries to load is 64-bit. At the breakpoint enter du poi(@esp+4) to print the first argument, which is the unicode path of the DLL it's attempting to load. Also check the stack trace via kc.

Using this hint, I found a dependency on a 64-Bit WinPCAP DLL. Going through everything with DependencyWalker, it looked the same on both machines, complaining about a 64-Bit dependency, but apparently on the fresh machine, the DLL load path was different and it could never find the 32-Bit version.

---

Related Topics