Showing results for 
Search instead for 
Did you mean: 

Problems calling external DLL in LabView 2019 vs LabView 2010

Hello dear forum users,

I have programmed a measurement software in LabView 2010 for a measurement device from the company IBR-MEsstechnik and I have been using their IBR_DDK-.dll-library (see download on the providers site:
The problem I have is that while using LabView 2010 (32 bit, and a Windows 7, 64 bit Version on my computer) it is possible to open the setup windows which are triggerd
by the specific .dll-functions. Now I have changed to LabView 2019 (32 bit, Os Windows 7 64 bit) and it is not possible to open any window which should be opend for calling
the setup-menu via the specific .dll-function.I have contacted the .dll-provider but they don´t seem to have a lot of experience using LabView. They gave me as an information
that their IBR_DDK-dll is using just the regular win32-API´s. According to them there should not be a difference in the behaviour calling .dll-functions with LabView 2010 and LabView 2019.
So now I am wondering why I can´t open the setup menu of measurement device via the specific .dll-function with LabView 2019. Using LabView 2010 everything works fine.

Have you encountered a similar problem or can you help me why the behaviour of the dll while using LabView 2010 and LabView 2019 is so different?
By the way I have both LabView versions 2010 and 2019 on my computer.

Please find a sample LabView-VI (provided by IBR Messtechnik via the IBR_DDK-Download) enclosed.


I thank you in advance for your help.

Thank you!



Enclosed you will find a sample VI provided by IBR Messtechnik.



Download All
Message 1 of 4

Hello Thomas,


You have build new LabVIEW code from scratches or tried to use the old one but in 19th version?

Have you installed all toolkits whit new LabVIEW version?

The best way to thank, is to give KUDOS
0 Kudos
Message 2 of 4



thank you for your answer! Sorry that I am quite late replying but I was kind of busy the last weeks and now I can 


Well, the problems I describe occur already when I am calling the .dll out of my VI within LabView 2019 Professional development suite. I didn´t even build an exe so far. But I am going to try this within the next few days.  


I just have regularly installed the DLL and included its functions as an LLB in LabView to be able to use them through the nodes call library function node. 


When I am switching to use LabView 2010 which is installed and working on the same notebook as LabView 2019, the call process of the dll-functions works properly and I can see the windows produced by the DLL-call and use their functions properly. 


When I am using LabView 2010, there is no issue. 


Do you have a clue, what is the rootcause for the different behaviour of my two LabView-Versions calling one DLL? 


If there is any further question, feel free to ask. I am working on this project right now. 


Thank you for your support. 



0 Kudos
Message 3 of 4

There was a helpfull "bug" in old versions of LabVIEW. Not exactly sure in which version that was removed. Back then LabVIEW did try to second guess the Calling Convention configured in the Call Library Node when the function names matched a certain name template usually used for functions exported as stdcall even if it was set to the default of using cdecl.


Around LabVIEW 2011 they removed that as I already mentioned here.


So most likely your DLL is using stdcall (as clearly pointed out in your attached PDF) but some of your Call Library Nodes are configured for cdecl. In LabVIEW 2010 nobody ever noticed as LabVIEW was silently fixing this up for the uncaring VI library developer. Not so anymore.


And yes there are good reasons NOT to do such sneaky "trying to be good" things. It's perfectly legal for a DLL function to have a name that resembles the stdcall naming convention but is exported as cdecl, and before that change you could not call such a function at all in LabVIEW!


Hmm I took a look at your VI and they all seem to be properly configured for stdcall. So what else could there be?


Please change the library path to only contain the DLL name without any path. Since it is in the system directory that is all that is needed and Windows will resolve it properly.


Are you trying to run this in LabVIEW 64-bit? Some of the Call Library Nodes are configured in a way that they might cause problems in that case. Other than what the document states you would need to configure a few paramaters differently to work for both LabVIEW 32-bitt and 64-bit equally.


HANDLES need to be configured as "unsigned pointer sized integer"

Same for void* parameters!

Rolf Kalbermatter
Averna BV
0 Kudos
Message 4 of 4