dll rashing LabVIEW

[vivekkde]

Hi,

I am encountering a strange behaviour of LabVIEW when calling dll.

I've a function in dll which returns the netwrok adapter handler through void pointer, the prototype of the function is

void *OpenAdapter( char *AdapterName);

Now this handle or the void pointer will be used by other dll function such as int CloseAdapter(void *AdapterHandle);

The way I a handling sharing of void pointer between functions is through Unsigned Int in labVIEW. I ams stroing the void pointer (rerutned from OpenAdapter, in Call Library node) as Singed Integer and passing the same void pointer to CloseAdapter(void *AdapterHandle); as Singed Int in Call Library Node.

Is it the right approach to deal with functions dealing with void pointers. it seems my application (uses those void pointers) works fine till closes LabVIEW. The moment I close LabVIEW, it crahses.

Can anyone please help me in getting rid of this error.

Thanks in Advance

[nathand]

Please attach your VIs, along with the header file for the DLL you are calling.

Try setting the error checking level to "Maximum" in the Call Library Function Node configuration; that may provide a more helpful error message.

It should be fine to store the pointer as an integer, assuming that this is a 32-bit system. If you are running a 64-bit version of LabVIEW, then you need to store the pointer as a 64-bit value. The Call Library Function Node provides a "pointer-sized integer" parameter for this purpose.

[teststand]

Hello nathand,

thanks for your reply.

i am not allowed to share the dll on public forums due to my company policy. but i can create an example one and will try to pass onto you.

but i am hopeful that someone might have encountered similar problem before.

[nathand]

I don't need the DLL, just the header file (the function prototypes) and the LabVIEW VIs that show how you configured the Call Library Function Node (CLFN). If you have proprietary LabVIEW code, you could move the CLFNs into subVIs and just share those, so that all I can see is the parameters for the function and verify that they match the function prototypes. Unfortunately without more detailed information there's no way to help you, and it's quite possible that the error is in the DLL and not in LabVIEW.

[teststand]

Here's my VI's that opens and closes the netwrok adapters.

In close adapter vi, i was giving a chance to release void pointer explicitly through DS Dispose PTR.vi

you can find function prototype in vi description or in comments in block diagram.

[Darin.K]

The last thing I usually check when a CLFN crashes LV is the calling convention.  Why the last thing?  Because that seems to cause about 95% of my LV crashes from calling DLLs so I am done checking.

[nathand]

To confirm: if you put those two subVIs in a top-level VI, with nothing else, and you run it, then close LabVIEW, it will crash? Are you sure you correctly configured the calling convention for the call library node? Do you check that the adapter handle is valid (or at least non-zero) after the OpenAdapter call? If you're trying to close an invalid handle, that could cause a crash.

You should definitely not try to deallocate the pointer yourself; let the library's function do that for you. LabVIEW won't know how to release the pointer (and any associated resources) properly, which could also result in a crash.

[vivekkde]

here's another vi that reads adapter statictics once it's opened with open adapter. LV will crash if main vi is called with this three sub vi's.

dll have logging function, once enabled returns all events happening in system. I have gone through one such log file when called through LV and have seen positive events.

Coming to non-zero pointers, yes my application will check everytime if open adapter is returning non-zero pointer and not NULL pointer before calling another function.

With null adapter name, open adapter will return 0 while for valid adapter name such as \Device\NPF_{EEDABC6F-F7EF-4E8A-AE6F-AAC8030D4997} (one adapter in my system) it returns valid pointer.

[vivekkde]

To confirm: if you put those two subVIs in a top-level VI, with nothing else, and you run it, then close LabVIEW, it will crash?

YES - everything works till I close LV.

sorry for not mentioning in last post.

[nathand]

Is the DLL written at your company? If so, any chance you can put a debugger on the DLL? Have you used this DLL in a non-LabVIEW application without crashes?

Does the GetAdapterStatistics call return a struct by value? That's what the prototype suggests, unless AdapterStatistics is actually a pointer type. If it is returning the struct by value, then I have no idea how you could access it in LabVIEW, and it will almost definitely crash as you have it set up now because you're trying to dereference a value that is not a pointer.