0

I got a dll which i want to load using ctypes.

from ctypes import *
mydll=cdll.LoadLibrary(r"C:\\test\\mydll.dll")

Its a 32 bit dll and therefore I'm using x86 version of Python (2.7.12).

The problem is that on my desktop pc (Windows 10) for some stupid reason i get that known error:

WindowsError: [Error 126] The specified module could not be found

I have no idea what is going on, tried changing pathnames as i read on other questions, tried to use windll instead, older versions of python nothing worked.

Then I tried running EXACTLY the same code on EXACTLY the same version of python on my laptop (Windows 10) and it worked....

I have no explanation what is going on, so I need some help. At least how am I supposed to debug the desktop situation. Its probably OS related?

Greg K.
  • 686
  • 1
  • 5
  • 18
  • 1
    Why double the backslash with `r`? Try `r"C:\test\mydll.dll"` – Moses Koledoye Aug 26 '16 at 19:22
  • How and on which OS was this dll compiled? Did you look at the accepted answer to this: http://stackoverflow.com/questions/1940578/windowserror-error-126-the-specified-module-could-not-be-found? – cdarke Aug 26 '16 at 19:30
  • @MosesKoledoye I've tried all combinations. They don't work. cdarke I have no idea. This dll was distributed like that. The fact is that its working great on my laptop. And i just used it as well, absolutely no errors. – Greg K. Aug 26 '16 at 19:43
  • Does same happens if you just place script in dll's place and set path to dll's name? – BladeMight Aug 26 '16 at 19:48
  • @BladeMight yes... Also i tried opening the dll with dependency walker. It reports a ton of missing dlls like msvcr110.dll but its directory is already in the system PATH. Gonna run the dependency on laptop to see whats the output – Greg K. Aug 26 '16 at 20:00
  • Perhaps this is an obvious question, but does `C:\test\mydll.dll` actually exist? – John Gordon Aug 26 '16 at 20:01
  • @JohnGordon lmao, i wish it didn't :( Just checked the dep walker on the laptop. it locates msvcr110.dll and msvcp110.dll. on the very same directory where the desktop dlls are. Why on earth can't the desktop OS find the dlls in system32... – Greg K. Aug 26 '16 at 20:05
  • 2
    WinAPI `LoadLibrary` (not the useless `cdll.LoadLibrary` method; just use `CDLL`) doesn't search a DLL's directory for its dependencies. It only looks in the DLL search path, which defaults to the application directory (e.g. the directory of python.exe), system directories, the current directory and the directories listed in the `PATH` environment variable -- in addition of course to the current activation context. To have the loader check the DLL's directory, call [`LoadLibraryEx`](https://msdn.microsoft.com/en-us/library/ms684179) with the flag `LOAD_WITH_ALTERED_SEARCH_PATH`. – Eryk Sun Aug 27 '16 at 01:49
  • @eryksun YOU ARE THE MAN. CDLL worked LIKE A CHARM. Btw i still don't get why its working, because like you said LoadLibrary searched in the system path as well, so it should have found the required dlls, but it doesn't. Thanks a bunch, if you want write this comment as an answer just to accept it. – Greg K. Aug 27 '16 at 09:23
  • I have no idea what changed to make it work for you. I meant that `cdll.LoadLibrary` is useless because it's a long-winded way to call `CDLL` that doesn't even let you pass any of the arguments that `CDLL` takes. Regarding the `LoadLibraryEx` suggestion, I guess I misread the question and comments. I thought that the C/C++ runtime libraries (msvcr110.dll, msvcp110.dll) were located beside "mydll.dll". That's why I recommended using the loader's altered search path. – Eryk Sun Aug 27 '16 at 09:51

0 Answers0