Under Windows, I'm trying to use a 3rd party DLL (SomeLib.dll
) programmed in C++ from Python 2.7 using ctypes
.
For some of its features, this library uses another COM DLL (SomeCOMlib.dll
), which itself uses other DLL (LibA.dll
).
Please note that this isn't about using a COM DLL directly from Python, but it's about using a DLL that uses it from Python.
To make the integration with Python easier, I've grouped the calls I want to use into my own functions in a new DLL (MyLib.dll
), also programmed in C++, simply to make the calls from ctypes
more convenient (using extern "C"
and tailoring the functions for specific scenarios).
Essentially, my library exposes 2 functions: doSomethingSimple()
, doSomethingWithCOMobj()
(all returning void
, no parameters).
The "effective" dependency hierarchy is as follows:
MyLib.dll
SomeLib.dll
SomeCOMlib.dll
LibA.dll
I'm able to write a simple C++ console application (Visual C++) that uses MyLib.dll
and makes those 2 consecutive calls without problem.
Using Python/ctypes, the first call works fine, but the call that makes use of COM throws a WindowsError: [Error -529697949] Windows Error 0xE06D7363
.
From the rest of the library behaviour, I can see that the problem comes exactly where that COM call is made.
(The simple test C++ application also fails more or less at the same place if LibA.dll
is missing, but I'm not sure if it's related.)
I've looked at the dependency hierarchy using Dependency Walker.
SomeCOMlib.dll
isn't listed as a dependency of SomeLib.dll
, although it's clearly required, and LibA.dll
isn't listed as a dependency of SomeCOMlib.dll
, although it's also clearly required at run time.
I'm running everything from the command line, from within the directory where these DLLs are (and the C++ sample executable works fine).
I've tried to force the PATH to include that directory, and I've also tried to copy the DLLs to various places where I guessed they might be picked up (C:\Windows\System32
and C:\Python27\DLLs
), without success.
SomeCOMlib.dll
was also registered with regasm.exe
.
What could cause this difference between using this DLL from a plain C++ application and from Python's ctypes
when it comes to its own usage of the COM mechanism (and possibly the subsequent loading of other DLLs there)?
Which steps would give at least a bit more information than Windows Error 0xE06D7363
from Python, to be able to investigate the problem further?
The Python code looks like this:
import ctypes
myDll = ctypes.WinDLL("MyLib.dll")
myDll.doSomethingSimple()
myDll.doSomethingWithCOMobj() # This statement throws the Windows Error
(The test C++ standalone application that works, linked to MyLib.dll
makes exactly the same calls within main
.)
When you need an in-proc COM object, you don't link directly to the implementing DLL. You usually use CoCreateInstance
/CoCreateInstanceEx
, which will load the DLL for you.
The lookup goes through the application's manifest and its dependant assembly manifests. This is done to support registration-free COM.
If there's no application manifest or if none of the dependant assembly manifests declare your class in a comClass
XML element, the lookup defaults to the registry, which will check HKEY_CLASSES_ROOT\CLSID
1 for a subkey named {<your-CLSID>}
, itself with an InProcServer32
subkey stating the DLL.
This explains why SomeCOMlib.dll doesn't appear as a dependency. It doesn't explain why LibA.dll doesn't appear as a dependency of it, probably because it's dynamically loaded. If you profile your app within Dependency Walker, you'll see a log of LoadLibrary calls in the bottom pane. To profile it, open your Python executable in Dependency Walker, then go to menu option Profile->Start profiling..., set the parameters to run your .py
file and click Ok.
The 0xE06D7363 exception code is a Visual C++ exception code. You should check the source code of doSomethingWithCOMobj
. To debug it, use your preferred tool (Visual C++, WinDbg, etc.), open Python's executable, setting up the arguments to run your .py
file, and enable a breakpoint on the first statement of the function before running the application. Then run it and step through each instruction.
It's really hard to guess what's different about your native C++ application and Python, but it may be that different COM initialization arguments are used by Python and doSomethingWithCOMobj
, or that you haven't declared it __stdcall
(although being a void function that shouldn't matter), or that it tries to write to stdout and you're using pythonw.exe
which isn't a console application, etc.
1.HKEY_CLASSES_ROOT
is a mix of HKEY_CURRENT_USER\Software\Classes
and HKEY_LOCAL_MACHINE\Software\Classes
.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With