CODEWITHSUNDEEP
c++dllserviceloadlibrary
CH4
CH4

Reputation: 105

Sometimes LoadLibrary fail with error code 126

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!

Upvotes: 0

Views: 2740

Answers (1)

nitroglycerine
nitroglycerine

Reputation: 171

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.

Upvotes: 1

Related Questions