Python Ctypes - Loading Dll Throws Oserror: [Winerror 193] %1 Is Not a Valid Win32 Application

OSError: [WinError 193] %1 is not a valid Win32 application while reading custom DLL in python with CTypes

This is a typical CPU architecture (032bit (your .dll) vs. 064bit (Python process that tries to load it)) mismatch. Check [SO]: Python Ctypes - loading dll throws OSError: [WinError 193] %1 is not a valid Win32 application (@CristiFati's answer) for more details.

Build the 064bit (pc064) version of your your .dll.
You can use the command line tools from the aforementioned URL, or you can set the VStudio IDE to do it, as explained in [MS.Docs]: How to: Configure Visual Studio C++ projects to Target 64-Bit, x64 Platforms:

1. Open the C++ project that you want to configure.
2. Open the property pages for that project. For more information, see Set C++ compiler and build properties in Visual Studio.
3. Choose the Configuration Manager button to open the Configuration Manager dialog box.
4. In the Active Solution Platform drop-down list, select the <New...> option to open the New Solution Platform dialog box.
5. In the Type or select the new platform drop-down list, select a 64-bit target platform.
6. Choose the OK button. The platform that you selected in the preceding step appears under Active Solution Platform in the Configuration Manager dialog box.
7. Choose the Close button in the Configuration Manager dialog box, and then choose the OK button in the <Projectname> Property Pages dialog box.

OSError: [WinError 193] %1 is not a valid Win32 application - python

My problem was with the compilation code
im used gcc -shared -o a.dll main.c instead of gcc -c -fPIC main.c -o a.dll

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.

OSError: [WinError 193] %1 is not a valid Win32 application

The error is pretty clear. The file hello.py is not an executable file. You need to specify the executable:

subprocess.call(['python.exe', 'hello.py', 'htmlfilename.htm'])

You'll need python.exe to be visible on the search path, or you could pass the full path to the executable file that is running the calling script:

import sys
subprocess.call([sys.executable, 'hello.py', 'htmlfilename.htm'])

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