I'm trying to compile the _ssl module on Windows for Python 2.6 using the MSVC compiler, because the Python runtime embedded into the host application is built with this compiler and of this version. The runtime does not come with native ssl-support on Windows however, not because it is not supported, but because (among an official statement) licenses have not yet been checked to be compatible with the closed-source application.
I've downloaded the CPython 2.6.8 source from the Python homepage and extracted _ssl.c and socketmodule.h (required include by the ssl module source) into a separate folder. I've also downloaded the openssl-for-windows win32 builds in order to linke it with the ssl module source.
My build-commands are the following:
cl /I"C:\path\to\host\python\runtime\include" /I"include/" _ssl.c /Fo"_ssl.obj" /c
link _ssl.obj /DLL "C:\path\to\host\python\runtime\libs\python26.lib" lib/libeay32.lib lib/ssleay32.lib Ws2_32.lib /OUT:_ssl.pyd
libeay32.lib and ssleay32.lib are from the openssl-for-windows distribution. The module compiles fine and outputs an 88KB shared library.
Problem
When I start the host application and run a command invoking the Python runtime running code importing and using the recently compiled _ssl module, the application crashes. The host application has its own kind of exception handler writing a bugreport when crashing.
Exception
{
ExceptionNumber = 0xC0000005
ExceptionText = "ACCESS_VIOLATION"
Address = 0x01A27058
Thread = 4776
Last_Error = 0x00000000
}
The call-stack at the point of the exception does not end in any Python related procedures. I assume that something incorrect happened before that triggers the error at this place.
Weirdness
When I run the application from the Win32 Debugger (WinDbg), this error does not happen and everything runs fine.
Question
What am I doing wrong with compiling the _ssl module, or what could trigger this exception?
Additional Information
The embedded Python runtime is the following: 2.6.4 (r264:75706, Mar 6 2012, 02:32:04) [MSC v.1600 32 bit (Intel)]
The crash finally was due to a bug in the host application. This bug could however only occure, when data was fetched from the web, which was only possible with the ssl module.
Related
I have a project written in Python 3.9 and C++ 17, with pybind11 as the glue. It works just fine when running alone or through various debuggers, like VS's debugger and NVIDIA Nsight. However, when running through RenderDoc (a graphics API debugger, with it's own Python bindings which I don't use) I get the following error in the terminal:
ImportError: DLL load failed: The operating system cannot run %1
The error if given out for modules in my project trying to import modules from my project.
At first the error message feels similar to ImportError: DLL load failed: The specified module could not be found, so I investigated in Process Monitor, but the module seems to be found just fine.
So I'm wondering, what on earth does this error message mean? What is the OS trying to do but failing at? What might cause it? How might I debug it?
Some other threads suggest it might be to do with Python 3.8's new add_dll_directory, but I don't see why adding some specific debugger would cause this when everything runs fine without it?
I don't think it is an environment issue, as I've run everything through the same terminal. Also, it ran through RenderDoc just fine before performing various library upgrades, including an upgrade over the Python 3.8 boundary.
I'm trying DolphinDB python API to subscribe a stream table from our DolphinDB cluster. But as I run import dolphindb it reports
ImportError: DLL load failed: The specified module could not be found.
As I read the readme for a second time, I found that only Anaconda python is supported, because of some issue of DLL loading.
But I cannot use Anaconda for some reason, so is there any workaround?
The c++ version python api is based on DolphinDB's c++ api. On windows platform, c++ api is compiled by mingw so that the runtime requires mingw's core dll. The non-Anaconda doesn't come with mingw runtime and hence failed to import the DophinDB python api.
The new version of python api has included mingw's required libraries. Please check it out.
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.
I am trying to freeze Python 3.3 code that uses PySide libs using cx_freeze and all of that on Windows XP (x86, SP2/3).
The python setup.py build runs successfully but the executable throws an ImportError:
ImportError: DLL load failed: This application has failed to start because the application configuration is incorrect. Reinstalling [...]
The same builds run perfectly fine on Windows 7 x64 (SP1).
The versions I am using are as follows:
Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit (Intel)] on win32
cx_Freeze-4.3.1.win32-py3.3
PySide-1.1.2.win32-py3.3
Both QT DLL libraries get copied to the build folder (QtCore.dll, QtGui.dll), the library-zip contains both .pyc equivalents in the PySide folder/module.
This issue occurs even with the simplest test-code (and also if the code is run on a "live" Python installation as well*):
from PySide import QtCore, QtGui
if __name__ == "__main__":
app = QtGui.QApplication("My Application")
win = QtGui.QMainWindow()
win.show()
app.exec_()
Using a more up-to-date version of PySide might fix the problem, but since PySide 1.2.0 introduces a new issue with cx-freeze (the file load error) I was wondering if anyone managed to freeze a PySide package on Windows XP stock successfully?
Otherwise will have to wait until PySide 1.2.1 gets published and keep my hopes for that release.
See my comment: I'm not sure if this really happened during my tests for actually the same reason or for other reasons e.g. the actual module causing the issue in the frozen builds not having installed properly..
Turned out there was a simple solution to the issue: A DLL from another module in use by the application was missing; copying it into the root build-out folder next to the frozen EXE easily solved the problem.
The best (and probably only) approach of attack to solve these issues probably is to copy all DLLs from used modules into the build dir one by one until the frozen build doesn't throw the error anymore. I couldn't find another way as the stacktrace didn't point to a specific file that failed loading.
If anyone runs into similar issues, I'd be happy to provide extra info.
I had a similar issue in the past and was able to resolve it by downloading the "Microsoft Visual C++ 2008 Redistributable Package (x86)".
Previously I have been trying to host multiple DEMO django projects using a virtual host on apache, and have been successfully with the help of stackoverflow.
Now I have been trying to host my new project using the same technique like the previous ones. My new project is connected to the sql_server database. My project runs perfectly when using djangos in-built server.
When i try running using apache i get an 500 Internal Server Error and my apache error logs shows -
Exception occurred processing WSGI script
ImproperlyConfigured: Error loading pyodbc module: DLL load failed: A dynamic link library (DLL) initialization routine failed.
My wsgi file looks like this -
import os
import sys
path = 'C:/path/project1'
if path not in sys.path:
sys.path.append(path)
os.environ["DJANGO_SETTINGS_MODULE"] = "settings"
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
And i do have "C:\Windows\SysWOW64\python27.dll" in my machine
My system -
Windows 7, Apache 2.2, python 2.7, django 1.4.2
Another info i found out on my machine -
Python 2.7 (r27:82525, Jul 4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32
Any solution towards this??
Thanks alot guys...
I managed to solve this problem, after spending severl hours googling for answers, finally found an answer here, and it says :
It appears that this dependency is being satisfied by running inside of python.exe (which is linked against the same). When the dll version of the python interpreter is instead hosted by another process, the windows sxs configuration applies the msvcr90 dependency only to the python dll.
This means that, in general, pyodbc.pyd (and likely pyodbcconf.pyd) will be unusable in embedded python on windows unless
the host application is linked against the appropriate version of the
msvc runtimes.
Use mt.exe (a freely available tool in the windows sdk) and try the commands on the command line.
Where do I get mt.exe?
mt.exe -inputresource:c:\windows\syswow64\python27.dll;#2 -outputresource:pyodbc.pyd;#2
mt.exe -inputresource:c:\windows\syswow64\python27.dll;#2 -outputresource:pyodbcconf.pyd;#2
Hopefully this wil be usefull for someone.
Cheers