3

I'm running into problems with a proprietary dll, which unfortunetly prevents me from posting the code here. Luckily the problem reduces down to two lines anyway:

import ctypes
windll.LoadLibrary("K:\\Patch\\To\\DLL.dll")

This code works with Python 2.7 but not with Python 3.5. In 3.5 in throws:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "K:\Miniconda\envs\...\lib\ctypes\__init__.py", line 429, in LoadLibrary
    return self._dlltype(name)
  File "K:\Miniconda\envs\...\lib\ctypes\__init__.py", line 351, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: [WinError 1114] Eine DLL-Initialisierungsroutine ist fehlgeschlagen

(Sorry about it being in German. Not my decision)

Error in English should be:

OSError: [WinError 1114] A dynamic link library (DLL) initialization routine failed

I've tested my Python 3.5 interpreter with "C:\Windows\System32\aadtb.dll" and it worked so it can load other DLL's.

The DLL I need to load is provided by a third party and closed source. The company we got the DLL from doesn't feel responsible and won't help.

So what my question boils down to: What are the differences between Python 2.7 and Python 3.5?

I know they changed the way errors are reported but I couldn't find anything else.

Edit: The DLL and both python versions use 64bit addressing.

Maximilian Peters
  • 30,348
  • 12
  • 86
  • 99
hank-der-hafenarbeiter
  • 49
  • 3
  • Does the DLL use the Python API? There are differences in coding between the two, plus it needs to be linked with the correct python DLL. Another possibility is that you are running either python or the DLL as a 32-bit and the other is 64-bit. – cdarke Feb 20 '18 at 14:41
  • Is your Python 3.5 installation 64-bit, maybe? 64-bit Python can't load a 32-bit DLL and an initialization failure is exactly what you can expect if you try. Though you usually don't get such an explicit message. – BoarGules Feb 20 '18 at 14:41
  • Both versions of python are 64bit as is the dll. @cdarke I don't know how the DLL was produced. All I know is that I can load it with windll.LoadLibrary(...) in Python 2.7. So it might be that this DLL can only be used with 2.7 and there's nothing I can do about it? – hank-der-hafenarbeiter Feb 20 '18 at 17:14
  • The *.dll* and *python* architectures match (otherwise the error would be different). One difference that could trigger this behavior is the *VStudio Runtime lib* used (*Python2.7* - *VStudio2008*, while *Python3.5* - *VStudio2015*). I'd suggest to check the *.dll* with *Python3.2* (I'd expect it to work), then one of *3.3* or *3.4*. In *VStudio2008*, *VStudio Runtime lib* comes as a dreaded assembly. Do you have the sourcecode for the *.dll* (if yes, you could build it)? Can you share the binary? – CristiFati Feb 20 '18 at 18:41
  • Likely related to the MSVC runtime libraries. The vendor of the DLL really should be helping you. Perhaps you could try to recreate the problem in a blank executable built in Visual Studio. Perhaps they'd help then. Link to MSVC runtime the same way Python does. – David Heffernan Feb 20 '18 at 20:12
  • 2
    In Python 2, msvcr90.dll will already be loaded, and you have the application activation context to work from. Python 3.5 uses the new Universal CRT. I suggest you use something like dumpbin.exe to list its dependent DLLs and mt.exe to dump its embedded #2 manifest, if any, to check for the "Microsoft.VC90.CRT" assembly. You should be able to add that #2 manifest externally, if need be, as a file named "DLL.dll.2.manifest". Here's an [example](https://stackoverflow.com/a/27392347/205580) that uses a dynamic activation context via ctypes. – Eryk Sun Feb 20 '18 at 20:19
  • If it is a dependency problem, a tool like SysInternals Process Monitor can be used to see exactly what DLL is failing to load. See [this answer](https://stackoverflow.com/a/18650202/235698) for an example. – Mark Tolonen Feb 21 '18 at 02:51
  • If you have the source code, anything happening in the *DllMain*? I get that posting code is not an option, but what about a "textual" representation? I'm interested if any *WINAPI*s are called (recursively) there. @MarkTolonen: Actually it's not a dependency issue (other error message). All the dependencies have been resolved, and *.dll* loading is in progress. – CristiFati Feb 21 '18 at 06:37
  • Sorry for being absent for almost a week. @CristiFati unfortunately, I don't have the source code myself. All we have is a compiled .dll with a documentation of the provided functions with their function signature. I investigated with dependency walker and strangely it failed on a bunch of missing functions in several system libraries like kernel32.dll. I would really like to use py3.5/6 though because futures would make my work a lot easier. I understand that there are packages that backport these features but we would like to keep non-std packages to a minimum. – hank-der-hafenarbeiter Feb 27 '18 at 08:27

0 Answers0