Wrapper DLL behaves differently when called from LabVIEW vs. a simple console application

[nathand]

Do you already have VisualStudio installed on the same computer as the one where you're running LabVIEW? If so, have you connected the VisualStudio debugger to your DLL (I think this is what TheWaterbug is suggesting)? I've had good luck debugging this sort of issue that way, because it lets you stop and look at exactly what the DLL is doing. I haven't done this recently but I think what you need to do is connect VisualStudio to LabVIEW, then set a breakpoint within your DLL code, and of course make sure the DLL was compiled to allow debugging.

[NiaccountAndrew]

Yeah VisualStudio is on the same computer as LabVIEW. I've connected the debugger to my DLL just now. However I'm not really seeing much from this. My wrapper DLL is extremely simple as its only making one call to the underlying API I am wrapping. This call is the source of all my problems. 

I tried running the debugger on both LabVIEW calling my wrapper as well as my test console. Attached is screenshot of how I get one result with console application, and another from LabVIEW. (note the different values of nDevices. the breakpoint was at the same point in the same DLL for both of these executions.)

Unfortunately I don't have pdb files for the underlying library dlls I am calling, otherwise I might be able to see if something different is happening.

[NiaccountAndrew]

Just to update anyone who comes across this thread- we managed to work around this issue by switching to Windows 7. We have no idea why this fixes the issue. It is bizarre that the same exact DLL calls would give different results when called from LabVIEW vs elsewhere, and that this happens when we have Windows 10 installed but not Windows 7. My colleague tried different versions of LabVIEW on the same Windows 10 system and ran into the same issue. It is possible it is some aspect in how our windows environment is configured, however we were unable to determine what exactly it was. 

[rolfk]

Does your secondary DLL maybe attempt to load other DLLs dynamically? This is often done where a user side API DLL presents a common API for application programmers to call, but this DLL loads different low level DLLs dynamically to support different protocols or hardware interfaces.

This is different from statically linking to those low level libraries. In that case LabVIEW would report that the main DLL you try to link could not be loaded, although strictly speaking it is not the main dll but one of the statically linked dependencies.

If the DLL however tries at runtime to load a number of secondary DLLs dynamically itself, loading of the main DLL will simply succeed, but the functions you call will end up reporting that 0 devices could be found since none of the low level drivers could be loaded.

Depending how the path of these dynamically loaded libraries is determined you can get this error easily.

In your command line exe program you copy your wrapper, the main DLL and any possible low level DLLs into the same directory as your exe. And if the main DLL loads these low level DLLs by name only (without path) Windows will find them in the current executable's directory.

Now take LabVIEW: You copy all the DLLs into the same directory but not where LabVIEW.exe is located. Your wrapper will be found for sure, since you specified the exact path to it in your Call Library Node. The main DLL seems to be found too, either because the import link library you use does something specific, or you actually added some code in your wrapper to load it exprictly from the correct path relative to your wrapper. But the main DLL trying to load the low level DLLs by name only will now fail to locate them, since Windows only looks in certain directories for DLLs loaded by name, and one of them is the executable directory, but that is in this case where LabVIEW.exe resides. It certainly will not look in any of your LabVIEW project directories for this DLL.