Develop Reference

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

I have a problem loading a Windows DLL in Ctypes, which throws the error:
WindowsError: [Error 193] %1 is not a valid Win32 application
In my case, it's a 32-bit DLL built with VS2012 on Windows 7 64-bit, and on my development machine I can load it fine. I checked that it's 32-bit, using dumpbin /headers:
FILE HEADER VALUES
14C machine (x86)
The problem occurs when I try to load the same DLL via Ctypes on a production VM, which is also Windows 7 64-bit. What I'm doing is:
from ctypes import *
self.dll = CDLL(dllabspath)
I get:
File "C:\Users\user\Desktop\WinPython-32bit-2.7.10.1\.....\__init__.py", line 365, in __init__
self._handle = _dlopen(self._name, mode)
WindowsError: [Error 193] %1 is not a valid Win32 application
From the other questions I've already tried several things.
This, this, this and this question suggests that my environment has to be the same, i.e. 32-bit Python, 32-bit DLL. This is the case on my development system and the VM I'm testing on. On both, I'm using WinPython 32-bit, latest version. It works on the dev machine, it fails on the VM.
Here, it's related to g++ and a dependency on old Visual Studio runtimes. I compiled everything with VS2012 so I don't think this is applicable here. There is a delayed-loaded dependency on a third party library that needs MSVCR80.dll, but it's delayed-loaded and never called.
I've also installed the Visual C++ 32-bit Runtime on the target machine.
This suggests that the DLL needs to export a C interface, which it does.
I know that the file path / file name to the DLL is correct, as before, there were issues with missing DLL dependencies, where I got a Windows popup. These are gone now.
The error is very generic, rather cryptic. Since it works on the dev machine in the same Python env, I'm assuming it has to do with some dependencies that only a Visual Studio installation can give me?
How can I troubleshoot this properly?

#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.

Importing urllib2 in SublimeREPL gives an ImportError

I installed SublimeREPL in Sublime Text 3, and it's working great. However, whenever I try to import a module that uses _socket such as urllib2 and urllib, it gives me an ImportError. I ran os.path to verify that the path was correct. It also works perfectly fine from the python command line, just not in SublimeREPL.
>>> import urllib2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "E:\Python27\lib\urllib2.py", line 94, in <module>
import httplib
File "E:\Python27\lib\httplib.py", line 71, in <module>
import socket
File "E:\Python27\lib\socket.py", line 47, in <module>
import _socket
ImportError: DLL load failed: %1 is not a valid Win32 application.

You're almost certainly mixing Python installations. That is, you've got SublimeREPL using a 64-bit Python, but you've also got a 32-bit Python on the same machine, and your PYTHONPATH is configured to point at the 32-bit Python's library instead of/ahead of its own.
Or, worse, you installed both Pythons to the same directory, and you have a single installation which is part 64-bit and part 32-bit. (If that's the case, you'll get the same error using Python from the command line.)
Mixing native and Cygwin Pythons, CPython and IronPython, or occasionally even two builds compiled with different flags, or two different X.Y versions, can also cause this, but 32-bit and 64-bit are the most common reason.
The reason urllib2 itself loads is that Python 2.7 source is Python 2.7 source code; it doesn't matter what build it comes from. But C extensions compiled into DLLs are compiled against a specific Python interpreter, and only work on that interpreter. If the Windows DLL loader hadn't refused to let Python get any further, you'd just get a different error a moment later.
While we're at it, Python improved the error handling for this case somewhere around 3.3, making it a little easier to tell what's going on, but of course if you stick with 2.7 you don't get new features.
From inside Python, the quickest way to tell if you're in a 32-bit or 64-bit interpreter is sys.getmaxsize. If it's about 2 or 4 billion, you're 32-bit; if it's about 9 or 18 too-many-digits-to-count-illion, you're 64-bit.
To find out whether a DLL is 32-bit or 64-bit is apparently a lot harder on Windows than on any other platform in the universe. See this question or this one for details.

I ran into the same problem. I suspected it had to do with using SublimeText 3 64bit and using a 32bit Python 3 for SublimeREPL.
I uninstalled Python 3 32bit, and installed 64bit Python 3 but this presented a new error about a version mismatch. I had installed Python 3.4 and my current version of SublimeText bundles Python 3.3.
So, I installed Python 3.3 64bit to match the bundled python of SublimeText 3 (Build 3083) and it finally worked. This is from within a REPL tab in Sublime Text:
Python 3.3.5 (v3.3.5:62cf4e77f785, Mar 9 2014, 10:35:05) [MSC v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib.request
>>>

How can 32bit modules run on 64bit Python?

I wrote a genetic algorithm program using the inspyred library with a 32bit Python2.7 version on a 64bit Win7 machine. While generating the population the program stops running when it uses memory up to 1959044K.
I have read a number of questions on this site, and I understand that it is due to a 2GB cap on 32bit programs by the OS. So I have tried to switch to a 64bit Python and install the 64bit versions of the modules I was working with, unfortunately all but one module cannot run on the 64bit platform.
I also installed pywin32 as advised in another question but that has failed to help too. This module is not a standard Python library and I have pasted it below. The error message I get is:
import AoN
ImportError: DLL load failed: %1 is not a valid Win32 application.
My understanding is that the 64bit Python does not recognize the 32bit module. I also read here: http://effbot.org/zone/python-compile.htm about compiling the source code, but I have compiled the source code in 64bit but that does not help either as it continues to give that error.
Lastly I pasted the directory path of the module in the interpreter path but that does not help too.
Is there a way to have this module run on the 64bit Python?
And please can anyone explain the process of compiling source codes and if that can help me out?

The answer is simple - it can't work. A process is either 32 or 64 bit, it's as simple as that. So if there is one module that can't run in 64 bit, one option besides re-compiling the module for 64 bit is to delegate whatever purpose it has to a second process running in 32 bit, just doing that. This might or might not be practical, depending on the actual task of the module.

Error "ImportError: DLL load failed: %1 is not a valid Win32 application"

I have this issue where I try to import cv2 on Python and get the following error message.
>>> import cv2
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: DLL load failed: %1 is not a valid Win32 application.
I do understand there are many posts about this where it is suggested that the bitness of the package is different from the Python package.
However, everything I am running is 64 bits. I am on Windows 7 64 bits, I have the winpython 2.7.3.3, 64 bits distribution, and I compiled OpenCV in 64 bits with the instruction provided here and placed the cv2.pyd DLL file in the Lib/site-packages folder of the Python interpreter.
Unfortunately, the suggestion of using the 32 bits version of Python isn't working for me any more as I have to handle NumPy arrays too large for 32 bits.
The only thing missing was to add the new NumPy binaries path (C:\opencv\build\bin\Release) to the Windows PATH environment variable, restart the Python interpreter.
Everything seems to be working fine now!

The ImportError message is a bit misleading because of the reference to Win32, whereas the problem was simply the OpenCV DLLs were not found.
This problem was solved by adding the path the OpenCV binaries to the Windows PATH environment variable (as an example, on my computer this path is: C:\opencv\build\bin\Release).

You could try installing the 32 bit version of OpenCV.

I just hit this and the problem was that the package had at one point been installed in the per-user packages directory. (On Windows.) aka %AppData%\Python. So Python was looking there first, finding an old 32-bit version of the .pyd file, and failing with the listed error. Unfortunately pip uninstall by itself wasn't enough to clean this, and at this time pip 10.0.1 doesn't seem to have a --user parameter for uninstall, only for install.
tl;dr Deleting the old .pyd from %AppData%\python\python27\site-packages resolved this problem for me.

Or you have to rebuild the cv2 module for Windows 64 bit.

This error can also appear when Python versions are mixed:
For example, if any of the DLL file to be loaded has been compiled using Python 2.7.16 and you try to import with Python 2.7.15 the error ImportError: DLL load failed: %1 is not a valid Win32 application. is thrown.
This is at least what I've found to be the problem in my case.

All you have to do is copy the cv2.pyd file from the x86 folder (C:\opencv\build\python\2.7\x86\ for example) to C:\Python27\Lib\site-packages\, not from the x64 folder.

I had the same error as the one mentioned in previous answers, but it happens only when I use pyinstaller.
I did the following in my Poetry venv:
poetry run python -m pip install pypiwin32
And it worked for me. I am using
python 3.8.10
pyinstaller 4.7
# Those are the versions that worked for me
pypiwin32 223
pywin32 303
pywin32-ctypes 0.2.0

When I had this error, it went away after I my computer crashed and restarted. Try closing and reopening your IDE. If that doesn't work, try restarting your computer. I had just installed the libraries at that point without restarting PyCharm when I got this error.
I never closed PyCharm first to test, because my blasted computer keeps crashing randomly... I am working on that one, but it at least it solved this problem... little victories... :).

Cx_Freeze DLL load failed

I have been trying to use cx_freeze for some time now, and yet the same error always occurs
import cx_Freeze.util
ImportError: DLL load failed: %1 is not a valid win32 application
I have tried with both 32 and 64 bit, and have tried both setup.py and cxfreeze.bat
what I am asking is, how do I make it work?

I have had the same problem and this was my solution.
I am using Python 3.2 for windows 64 bit and my library installations were all for 64 bit, including cx_freeze. When I tried to "freeze" a program that imported the PyQt4 package, I got the error:
ImportError: DLL load failed: %1 is not a valid win32 application
In my case, the problem was that the cxfreeze script was copying two DLL files (QtCore4.dll and QtGui4.dll) from my MATLAB installation, rather than from my Python installation. The MATLAB DLLs were 32 bit whereas the Python DLLs were the required 64 bit files.
Read the messages displayed when you run the cxfreeze script to build your exe files. The last few messages should be "copying ...dll-> ....dll". Check the filenames and make sure that all the files are actually being copied from your Python installation and not some other program.
If they are being copied from elsewhere (as in my case) you can simply copy them over yourself after the build. Otherwise, you will have to change your path not to include the folder containing the 32 bit DLLs from whatever program they belong.