Why does LabVIEW sometimes hang when DLL loads into memory?

[BT_Maryland]

I'm calling a third party DLL from LabVIEW 2010.  LV occassionally hangs (Not Responding) when either loading the DLL into memory or when closing my main VI.  When it doesn't hang, it communicates with the DLL seamlessly.  When I try to build an Application (exe), LV always hangs during the build at the point that it is saving the main VI (the scroll on the builder moves until it says "Saving main.vi").  Any insight into what needs to be done to the DLL (or VI) to resolve this issue?

[rolfk]

What does the DLL do? One cause of this could be to try to load/unload other DLLs in PROCESS_ATTACH or PROCESS_DETACH of DLLMain. Microsoft has in many places said that doing this is highly unsafe and asking for all kinds of troubles, since the DLL loading is not fully reentrant.

Another possibility would be incorporation of ActiveX components that use some form of RPC mechanisme to communicate with out of process ActiveX/OLE components. The necessary RPC proxy hooks into the calling processes message loop and that is a delicate piece of code in LabVIEW. Even when the DLL does not use ActiveX itself, it might employ some message hooking on its own and mess up things in a way that Windows and/or LabVIEW get confused.

[FraggerFox]

http://zone.ni.com/devzone/cda/tut/p/id/11869#221113_by_Category

Have you checked the above link? There are some known issues in LV2010 with CLFN.

Have a manual text search for CLFN and "Call Library" on the above link and see if the workaround for it fixes your issue.

[BT_Maryland]

Thanks for this reference.  Yes, I've tried both calling conventions and am sure that I have the right one (c).  What is puzzling me is that I open the VI with the Call Library Function Node in it.  Without running it or making any changes, I then close the VI.  It closes and then Labview hangs/crashes. 

This article says that the DLL is loaded into memory when I open the VI (even without running it):

http://digital.ni.com/public.nsf/allkb/342720607C60CEB78625706F000722FD

The second to last bullet in this article says that this behavior can occur when the DLL corrupts the memory:

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

So it seems that when the DLL is loaded, it is corrupting the memory and this is causing LV to crash.

Since I'm not a c developer, and the developer for the third party DLL doesn't speak Labview, I'm not sure what to tell him about managing memory.  Does it look like I'm on the right track here?

Thanks enormously for your help!

[cb3]

Did you ever receive a response to your last question? I'm having similar problems with a vendor's dll. I always knew that there were problems with this dll before LV-2010 but at least my code would execute. I just couldn't re-start the Main VI after stopping it. With LV-2010 I'm lucky to get it to run at all. The vendor's dll was created primarily to be used within C-code and most likely memory doesn't get cleaned up properly when using within a LabVIEW call.

[JordanG]

Hey cb3,

Some of what is contained in this article has already been mentioned, but take a look at this KB.

Why Does LabVIEW Crash When I Call My DLL?

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

Jordan

[BT_Maryland]

cb3,

I didn't get it fully resolved, but I did manage to build the executable, which is what prompted my post.  In the Call Library Function configuration, rather than navigating to the dll through the file directory, I checked the "specify path on diagram" check box and provided path constant on the block diagram to locate the dll.  This change allowed Application Builder to build the executable.  It also reduced the frequency of LV hanging, although it would still often hang after running the program.  I suspect that when the dll path is identified in the CLF configuration, LV loads the dll when building the executable - hence the hang (and when the VI is loaded into memory - hence the frequent hangs even when not running the program).  When specifying the path only, the dll is only loaded when called, and not when building the .EXE.  When coding the VI, it also isn't loaded until you actually run the program.

I hope this is helpful.  I feel your pain.  When I first started the process, I could hardly load the VI without LV hanging.  This helped a bunch.