1097 error on first DLL call, then later a LV crash

[Mr_Hardware]

I am calling a DLL and and the first time I run the VI, I get the dreaded 1097 error ("call library function node").

But the 2nd, 3rd, 4th, 5th time I run it, it works perfectly.

Then on the 6th time (every time), Labview crashes with an access violation...    Exception: Access violation (0xC0000005) at EIP=0x0A22191B

Any idea what what could cause both the 1097 and the crash?

I'm using Labview 11.0

The dll is proprietary, designed by an engineering firm, and their windows terminal program (that they also wrote) works perfectly with it.

- Paul

[RavensFan]

What does LabVIEW.dll do?  Where did you get it from?

Does it fail on the 6th run of your VI, or the 6th iteration of your while loop?

You have a node called connect, one called send command, and then receive message continuously in a loop.  I would assume that if you have a connect command, then you should probably have a disconnect command after the loop when all is said and done.  Otherwise resources are probably left open in this .dll (whatever it does) and that is leaving it in a state that eventually crashes.

[nathand]

In the Call Library Function Node, try configuring Debugging for Maximum and see if that eliminates the crash or at least provides a more detailed error message.

Can you post the code for the sample terminal program?  That would make it possible to compare with your LabVIEW code.

[Mr_Hardware]

A few answers:

The DLL came from a design firm who wrote it for us.  It connects to a glucose meter over USB 2.0.  It seems to work fine for them.  They provided a Windows EXE terminal program which was written in C, and it works.  The loop in my code only executes once before receiving the data, but the 6th time I run the VI is when LV crashes (access violation).

I did turn on Maximum error checking in the DLL calls, nothing changed.

I also added the Disconnect at the end of the sequence, for better hygiene.  Now I get 1097, it works OK the 2nd time, 3rd time I get a LV crash (access violation) and then it hangs forever.

[RavensFan]

One issue with calling .dll's in LabVIEW is that the .dll can work with memory locations directly, and if you don't have the .dll call set up properly, the dll can stomp on parts of memory that it shouldn't.

I suggest reading any threads in the forum regarding dll calls, and particularly ones that rolfk wrote.  He might pick up on this thread soon and be able to help.

If you have any information on the headers for the functions and post them, that could help someone like rolf (not me because I'm not familiar with C programming) to determine if the function call is set up properly.

[rolfk]

Your problem is most likely output buffers that need to be passed to functions you call. There is no managed code when calling C functions. How buffers are allocated and freed is up to the imagination of the DLL programmer.

The most common and accepted behaviour is that any memory used by a function to return information in, must be provided by the caller. Every good C programmer has that ingrained in his or her brain cells and automatically takes the necessary precautions when calling such functions, by allocating memory for the output parametes before calling the function, or declaring static memory buffers to pass to the function.

A typical LabVIEW programmer is normally not bothered by such requirements, as the managed environment in LabVIEW makes sure memory is allocated and freed automatically whenever necessary. However the DLL interface does not provide enough information to LabVIEW to do that automatically for DLL parameters. So it has to rely on the programmer configuring the DLL node, and if that is a LabVIEW programmer without some good C programming experience he or she will in 99.9 % of the cases forget to preallocate all output parameters properly.

If you call functions that accept a string or array to return data in, you have to make sure that buffer is allocated large enough that the biggest possible information returned by the DLL can fit in. Otherwise the DLL will overwrite other memory in the assumption that you provided it with a valid pointer to a memory area it can legally write to.

How big such buffers have to be can only be found out by reading the documentation (or when lacking such documentation looking at some C example code about how to call that function, which obviously requires some C programming knowledge, although I consider this a suboptimal solution since you don't know if the example was written by the developer who knows his function intimately or some nitwit who just tried with some random buffer size and declared victory after it didn't crash the first time).

Since C is not managed, and doesn't provide nearly enough information for a managed environment like LabVIEW to do the management of the API automatically, the caller of the C APIs, also if that is through the Call Library Node in LabVIEW, has to do all the management of buffers and such manually. A C programmer doesn't expect otherwise, a pure LabVIEW programmer is spoiled and often doesn't realize that this issue exists.