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

[NiaccountAndrew]

I'm currently writing a wrapper for a C++ library so that I can properly use it from LabVIEW (it unfortunately makes extensive use of C++ classes so a wrapper is necessary).  I am getting stuck for some reason because the first call to the library (a call which enumerates all relevant devices connected to the computer) consistently returns zero whenever the wrapper is called within LabVIEW. However, when I write a test console application which calls my wrapper DLL it works as expected- I get a "1" indicated that I have one device connected to my system. 

Here is my wrapper code:

#include "stdafx.h"
#include "libWrapper.h"
#include "lib.h"

using namespace std;
int initializeDetector() {
	int nDevices = 0;
	LibScanner scanner;
	nDevices = scanner.ListDevices();

	return nDevices;
}

 And the corresponding header file:

#pragma once
extern "C"
{
	__declspec(dllexport)  int initializeDetector();
}

Here is my test console application:

#include "stdafx.h"
#include "libWrapper.h"

int main()
{
	int numDetectors = 0;
	numDetectors = initializeDetector();
	printf("\nFound %d devices\n", numDetectors);
}

This outputs "Found 1 devices" when run from console. 

Attached is a snippet for when I use call library function node to call the initializeDetector function from my wrapper. When doing this it always returns a Zero (and does not throw any exceptions). For some reason the library call is not functioning properly when called from LabVIEW even though it does not give an exception, it just erroneously states zero devices are connected. I've tried numerous modifications of my labview call as well as to the wrapper and continuously get the same result. I've tried verifying that all the library DLL files are appropriately available in the same folder as my VI and wrapper DLL. However, my console application and other example programs shipped continue to work and I can't get a single Labview call of the wrapper to work. 

I've tried running LabVIEW first thing after a reboot to make sure it isn't the bus getting reserved for a different program, and this does not help. 

Thanks for any help you might have with this. 

[Dane.S]

Interesting problems there,

I was wondering if you were able to call any other DLLs in LabVIEW that work correctly or is it just this one that you made that does not work correctly? It's definitely strange that it works in the console but not in LabVIEW. 

Dane S. 

[NiaccountAndrew]

Yeah, calling other DLLs seems to work fine. And when I modify my wrapper to manually return an arbitrary number (for instance 100), it works appropriately. Somehow something different is happening when LabVIEW calls my wrapper DLL vs when other programs call it; however, whatever it is only relates to calls to the underlying library the wrapper is for. 

Thanks.

[nathand]

Have you checked the error output from the Call Library Function Node? If I had to guess, I would suspect that it's failing to find or load the underlying DLL (the one your wrapper calls, that includes the LibScanner class. You may need to either move DLLs around on disk or change path settings to make sure that the dependent DLL can be found at runtime.

In addition to checking the error out, you might also try changing the error checking level in the Call Library configuration to "maximum".

[JÞB]

Have you tried running LabVIEW as administrator?

Your library path is C:\

What happens if you run the DLL Import wizard?

[TheWaterbug]

LOL! I was searching for my own thread, saw yours, and thought it was mine :D.

I just had a very similar problem with calling 1st DLL that calls a 2nd DLL. When we ran our text script out of our own C++ application, it worked fine. When I ran it out of LabVIEW, the call to the 2nd DLL failed.

And now it works, and we didn't change anything, other than installing our C++ compiler so we could debug the 1st DLL. We didn't change anything in the code or in the script, but now it works.

So I'd recommend installing your C++ compiler so you can debug it. It just might magically fix itself.

[NiaccountAndrew]

Nathand, I tried to find errors however there are no errors-> it seems that its calling the wrapped DLL's function properly, but for some reason I get a different answer from when it is called outside of LabVIEW. That is the underlying DLL returns that 1 device is attached to my computer when called from within a test program that calls my wrapper, however trying the same in LabVIEW the function returns a different result. I did change error checking to maximum.

To verify the DLLs are properly loaded into LabVIEW I used the sysinternals "process monitor" tool and I see that all of the underlying DLLs that my wrapper calls are being loaded by LV without issue. 

[NiaccountAndrew]

Hi Jeff,

I tried and still get the same results (both running LabVIEW as admin as well as the DLL import wizard). I also verified that the necessary DLLs are being loaded by LabVIEW by using the sysinternals process monitor tool, which shows all relevant DLLs as loaded by LabVIEW. 

[NiaccountAndrew]

Yeah that does seem like the same exact error. I am not quite sure how to go about this. I am using Visual Studio 2017 (SDK 10.0.15063.0) with toolset v141. Maybe I will just try reinstalling Visual Studio? 

Most frustrating part of this is that the external library call is apparently working properly, it just returns a different (incorrect) result when called via LabVIEW. Its almost as if the DLL I'm wrapping has built in features to prevent working with LabVIEW (but I highly doubt this is intentional, whatever it is). 

[TheWaterbug]

I still haven't quite figured out exactly what was causing our 2nd DLL to fail before, nor how it fixed itself, but one possible cause could be paths.

Our DLL assumes that the working directory is the container of the executable that loads it, and that the 2nd DLL is in a subdirectory of that.

So when we ran it from our terminal-type application it was running from our application default directory, and when we ran it from LV it was running from \Program Files\National Instruments\LabVIEW 2017\