Error 1097 when calling DLL from LabView

[WNM]

I am getting an Error 1097 when calling a vendor's library from LabVIEW. Oddly enough, with the error, the DLL routines still seem to do what's being requested of them.  This is the test code.  It opens an Ethernet connection to a Galil motion controller, (optionally) asks it for the value of its internal clock and then closes the connection.  Each call-library function returns the 1097 error but "function-return" I32 error number is always zero. The open function causes the connection to be opened, the command function causes the command to be sent and receives a reasonable response, the close funtion seems to cause the connection to be closed.

Here is what I see when I run the test:

Besides directly configuring the call-library functions as I have done in this VI, I have also tried using the import-shared-library wizard to create a vilib from the DLL's functions and I get the same behavior and errors when I use those functions.  I have tried tweaking some of the data types in my manually-configured call-library functions to see if I could find a combination that worked better with the library but had no luck there.

I am using the x86 version of the DLL with 32-bit LabVIEW v2014  on a 64-bit windows 7 system.  I see the error on two different work computer systems configured this way. I see a similar error on a home system with just the 2014 RTE installed. The manufacturer says they cannot reproduce the error. I have consistently seen the error over multiple versions of their DLL library.

In the ZIP attachment there is a link to the DLL library on the manufacturer's website. There is also a copy of the VI, the DLL and much of the how-to-use documentation that accompanies the DLL.

I was hoping that someone who was familiar with the use of the call-library function could take a quick look at what I'm doing and see if a mistake could be spotted.

Lacking finding a mistake I've made, I'd welcome any suggestions about how I might troubleshoot this. It sort of looks to me like there may be a problem with the library. The manufacturer, Galil, says they opened a problem log with NI to see if NI could help but since Galil says they cannot reproduce the problem and provide an example to NI, it has not really gone anywhere.

[rolfk · Accepted solution]

Considering the name decoration of the symbols as exported by the DLL I''m convinced you should change the calling convention to stdcall.

[WNM]

Wow Rolf, I was hoping you'd see this topic and weigh in with a suggestion and here you had the answer in less than one line of text! Thanks!

I'll show my ignorance here and ask you what you mean by "name decoration of the symbols" and how it provided the necessary clue?

[rolfk · Accepted solution]

Two possible glues here.

1) In recent versions of LabVIEW if you look at the Call Library node configuration node you see in the lower part the actual function prototype.

That does require to set the library path to the actual DLL though in order to work. You then see the function name with the @ and a number appended. This is the default name decoration for stdcall exported functions. It's not a 100% sure indication but in most cases good enough. It's both possible to cause the compiler to emit such decorated names despite using cdecl as well as suppressing those postfix decoration despite using the stdcall convention. But it is some hassle to do and therefore usually not done by most programmers, especially since it does not serve any usueful purpose.

I personally have Dependency Walker installed on my machine which you can configure to be the application to open for DLL files and it lists all DLL dependencies of a Windows DLL or EXE file and also the exported function names etc. That is how I usually look at DLLs.

2) Looking in the header file that you have added to the the ZIP file is a more sure way. there you see the define for 

#define GCALL __stdcall //!< Specify calling convention for Windows.

This shows clearly that the DLL was configured to be compiled with the functions to use the stdcall convention.

Again the existince of this declaration is conclusive when added to a function prototype but the absence is no guarantee that the function doesn't use stdcall anyhow, since you can also force the C compiler to use stdcall convention by default instead of the cdecl convention.

If everything else fails disassembly of the function is the only sure way to guarantee what calling convention is used.

[WNM]

Thank you again for taking the time to look at this and explain the reasoning behind the soulution.