Calling a DLL file

[mini09]

Hi folks,

I'm trying to call a dll file using call library function and have some difficulties. Initially I got error 1097, later when I saved the file and run it, LabVIEW application close? Is it because i'm causing the LabVIEW application more memory?

[timtamslam]

Have you had a look at the troubleshooting steps in this document? I would give them a try. 

Why Does LabVIEW Crash When I Call My DLL?

http://digital.ni.com/public.nsf/allkb/7253D2F0D91F68058625752F005AB672

[rolfk]

From the header file the OpenUSBDevice() function has this prototype:

__declspec( dllimport ) BOOL __stdcall OpenUSBDevice( int*, int*, char* ); 

While you got the stdcall calling convention right you did mess up the parameters for sure. The first 2 should (could) be right (without full documentation to that function I never would say they are right 🙂 ), but the last is a pointer to a char (array) not a pointer to another int32 value.

So you probably want to configure that parameter as a String datatype and as subtype as a Pointer to a C String instead. And the function has a BOOL return value. The Windows BOOL datatype is really a 32 bit integer value where 0 means FALSE and anything else is TRUE.

[mini09]

Hi Tim,

I went through some of the discussion forums before posting this thread. I'm not sure what's the mistake in the code causing this problem to close the LabVIEW instead throughing me an error message.

[mini09]

Hi ROLFK,

All I have is the zip file (.h,.dll, .lib, .ini) format documents to communicate with the device remotely. I made the last StrMessage as string as you suggested. When I try to run it the result is same LabVIEW closes as a result of execution.

[timtamslam]

Hey gnshmrthy, 

I was able to reproduce the crash and fix it by updating the prototype for the szErrorMessage from int pointer to Cstring pointer, which is the correction that Rolf mentions.

Can you show us your current setup with the corrected "StrMessage" that still causes a crash?

[timtamslam]

Also, you may find the import .dll wizard worth looking into. It can create simple wrapper *.vi's for the functions you select in your *.dll. This might help cut down some time in configuring your CLFN's. 

http://zone.ni.com/reference/en-XX/help/371361L-01/lvdialog/import_library_wizard/

http://zone.ni.com/reference/en-XX/help/371361L-01/lvexcodeconcepts/importing_shared_library/

[mini09]

Hi Tim,

Here's my updated parameter,

Am I correct?

[timtamslam]

Yes, it looks like your interpretation of the Cstring is right now. 

I'm confused though. The original Test.vi, and *.h show OpenUSBDevice as only having 3 parameters... but your latest picture now has 4. Where did the new function prototype and 4th parameter (OpenUSBDevice) come from? 

For reference, i've attached my VI (saved to 2012, let me know if you need an older version) that works and a picture of the result.

[rolfk]

Ohh well, when I said that the function has a return value, I didn't mean to add another parameter to the function with the same name as the function.

In the parameter list you see an entry return type. This should be changed from void to int32 instead. And not not as a pointer to value but simply as value.

And Timothy, you forgot to set a minimum size for the string parameter. As it is now you pass in a string constant with 0 bytes length. Since it is passed as C string pointer LabVIEW will create a memory buffer with one single NULL byte and pass it to the DLL function. That function writes whatever it wants to write into that buffer, overrunning its 1 character limit in every single case where it returns more than an empty string. Kabooom! although not necessarily everytime and often not directly at the execution of this function but only later on! But memory corruption of one way or the other happens at every execution of that function.