LoadLibrary error 126 "The specified module could not be found"

[Captain_Jack]

We've got a problem attempting to load one DLL from another DLL, when using TestStand and the DLL Flexible adapter calling a third DLL (top level that loads the other DLLs).

I can't get it to work properly when I call the Initialize function in DLL A, which loads DLL plugins using the LoadLibrary SDK function. For one of the DLL plugins (DLL B), it uses functions located in another DLL (DLL C), that we created in CVI. DLL B does not call the LoadLibrary SDK function to load DLL C (but it is explicitly linked via the LIB & H files to DLL C). We pass the full path to the DLLs that we are trying to load using LoadLibrary, and all DLLs and LIBs are located in the same folder.

The problem is, DLL B never loads and returns NULL from LoadLibrary and GetLastError = 126 "The specified module could not be found". We know that DLL B never loads at all because it never calls DllMain, which I have set a breakpoint at. We believe that for some reason, LoadLibrary cannot resolve the location of DLL C, even though it's in the same directory, and the path to the directory is in the Path environment variable. And this is the file that "can't be found".

If we call the DLL A Init function from an executable instead, DLL A loads with no errors, and by extension so does DLL B.

If DLL B is loaded directly into TestStand with a direct call to DLL C before calling the Init of the DLL A, then DLL B loads with no errors.

If we remove the code provided by DLL C in DLL B, DLL B loads with no errors.

All DLLs look good in Dependency Walker.

Each DLL plugin can be loaded in TestStand by calling functions directly - so it appears to be case of how CVI and/or Windows is handling the implicit loading of DLL C from DLL B when DLL B is loaded by LoadLibrary in DLL A using TestStand.

We believe this worked at one point, but we don't know exactly what's changed to cause this behavior, and because everything is linked into everything else, even though we are controlling our software, it is still difficult to determine where the changes to the source occurred that caused the issue to occur.

Any help in pointing us in a direction of where to look would be greatly appreciated.

System Config: 

TestStand v4.1

CVI 8.5.0

WinXP SP 3

Thanks,

-Jack 

[Adri_K.]

Jack,

What happens when calling DLL C using the LoadLibrary SDK function instead of explicitly using the  LIB  & H files? Could you also provide a simplified version of the 3 DLLs and a sequence file that calls these DLLs and reproduces the behavior you are experiencing?

Regards,

Adri Kruger

Applications Engineer
National Instruments
http://www.ni.com/support

[Captain_Jack]

Adri,

To clarify, we are implicitly (statically) calling the DLL using the LIB and H files, as per the description in the DLL FAQ. That is what does not work for us. It would be a bit of work to explicitly (dynamically) call DLL C, but if we have time I will attempt it. I also don't know if I will be able to create a simple example that does the same thing, as we're under a deadline to get this working and we have a workaround of including the source from DLL C in DLL B.

-Jack

[Adri_K.]

Jack,

There has been a behavior change implemented in TestStand 4.0 and later that modifies the search order for subordinate DLLs for LabWindows/CVI and C/C++ DLL Adapters. Please reference the NI TestStand Version 4.0 Release Notes (page 😎 for this documentation. Please confirm that your directory structure complies with one of these directory search orders.

-Adri K