Sometimes LoadLibrary fail with error code 126

0
votes

Currently, I'm using LoadLibrary function to load my xxx.dll file (xxx.dll is my private dll file). It works normally, however, sometimes it fails to load library with error code 126.

MyDll = LoadLibrary(DllPath.c_str());

DllPath (of type std::wstring) is the path to my dll file.

I researched the error and it means that "The module could not be found", but I checked that the directory is right and the dll file still exists.

My dll file is a 32 bit dll and OS is windows 64 bit and dll file is loaded when starting service.

It rarely happens and currently I cannot reproduce this error. However, whenever the error happens, it will be always failed to load dll file and there is only one way to fix this is removing and reinstalling the software.

Does anyone know what is the possible reason of this issue?

Any help is appreciated!

1
c++dllserviceloadlibrary
How did youn check the directory is right? Where is the program located? - The Techel
This has been happening to me as well, and while it appears to be completely random at a first glance, I actually hadn't seen it fail ever if the DLL "wasn't loaded recently". My current workaround is running a while loop (with a maximum number of attempts) until the DLL is loaded successfully, and sleeping a random time between attempts (duration 10-1000 ms, not a problem for me as I'm in a thread dedicated to loading large DLLs, which is going to be blocking for a non-trivial time anyways). - John Weisz
@TheTechel : when the issue happens on my PC, I have printed a log of directory of dll file and it is right and I also have a function to check that the dll file still exist. - Cuong Huynh
@JohnWeisz : I also have a while loop to load dll file until the DLL is loaded successfully and have a sleeping time between attemps, however, it cannot reload for some days and it only is loaded when I reinstall my software. - Cuong Huynh
@TheTechel : Program is located in C:\Program Files (x86)\software's folder - Cuong Huynh

1 Answers

0
votes

I had once encountered this issue with a private DLL; I had a test program that performs a LoadLibrary against the private DLL and I got error 126. I took a look into it and was able to fix the error:

It appears this happens because of static vs dynamic link against the DLL's dependencies. More specifically, the private DLL depends on OpenCV, and links against the following files:

zlib.lib, ippicvmt.lib, ippiw.lib, ade.lib, opencv_core410.lib, opencv_imgcodecs410.lib, opencv_imgproc410.lib, ittnotify.lib, IlmImf.lib, libjasper.lib, libjpeg-turbo.lib, libpng.lib, libprotobuf.lib, libtiff.lib, libwebp.lib, quirc.lib

Those OpenCV library files can be either built in "static" mode or "dynamic" mode. When these files are built in "dynamic" mode, LoadLibrary of the private DLL gives error 126. When OpenCV is built in "static" mode, all the OpenCV routines will become part of the private DLL, the private DLL becomes larger (28 MB vs 41 MB), and the private DLL can be loaded correctly with one LoadLibrary call.

Some other findings:

  • My private DLL uses Unicode encoding, while OpenCV is built using multi-byte encoding. This combination works fine.
  • My OS is 64 bit, my private DLL is 32 bit, and OpenCV is built in 32 bit. The private DLL's bitness needs to match its dependency, OpenCV's bitness.
  • When building both the private DLL and OpenCV in Debug mode, the Iterator Debug Level of OpenCV and the private DLL must match. This issue does not exist when both are built in Release mode. This issue should also be paid attention to when mixing and matching debug mode and release mode.