How to terminate VB process that calls VI Dll Library when application closed

[SolarLR]

I have simple VB application to call VI DLL library. The problem is the VB executable file will reside in processes list even close the VB application. Looks like VI DLL does not free from memory when VB application unloaded. Did I miss something to terminate or unload VI DLL in VB program or VI program?

[Spex]

SolarLR,

Is the dll behaving as expected within your VB application?  By that I mean, is the dll returning valid data to the VB application?

How have you determined that the LabVIEW dll is what is still residing in memory?  Does the VI that was compiled into a dll contain a while loop that could be causing it to run infinitely?

Finally, if you remove the call to the LabVIEW dll from your VB application, does the application remain in memory after you close it?

Cheers,

[SolarLR]

Hi, Spex,

Thanks your response.

The way I figured out the VB executive process still resided in process list is opening task magnager to see if that executive process stayed in processes list after terminated VB application. I did implement a while loop in VI program but definitely stopped loop before returned back to VB application. From VB, I can call DLL functions as many as wanting without hanging up application. Just verified the while loop is not the root cause of issue.

Funny thing is there is no issue when DLL functions were called from VB6 or .NET developping/debugging environment. However,  process is not terminated or freeed from memory after exited/quited VB6 or .NET stand-alone application. I looked at every NI DLL knowledge base has no article mentions this problem. 

[Lycangeek]

I've got some questions for you also...

1. What version of LabVIEW are we talking about?

2. What exactly are you doing in the VI (any UI display, any loops, etc?)

3. Can you reproduce this with a very simple VI (ie, a blank VI compiled into a "void foo()" DLL call?

I've worked with several people (including myself) that have called LV DLLs from .NET so I know it works in the general case. We just need to figure out what's special in this case.

[SolarLR]

Hello, Brain,

Actually, the VI programs were cereated with LabView version before 7.0 or somthing. However, DLL was compilied with LabView 8.2. The VI programs that call serveral subVIs contain no UI displays but do have some while loops. There is no problem to run VI programs if compiled to executable file. Nor does simple VI DLL reproduce issue.  

[Lycangeek]

Well, I'm afraid we're down to good old-fashioned debugging tricks - something is happening that the OS doesn't want to kill. You can try to comment out sections of the VI (new feature in LV 8.2!) to see when it starts to work, or review the code looking for things like event handlers, callbacks, mutexes, open file handles, etc. It's hard to say what going wrong at this level. Also if you are calling out to 3rd party code (Call Library Node, ActiveX, .NET), make sure that it isn't creating such items and holding onto them.

General rules of thumb...

1. If you don't have a shutdown VI, or some sort of reference close VI, each VI you call from outside (DLL function) must exist with nothing left in LabVIEW - for example, no registered event handlers, no open file handles, etc. Just like camping, "leave it like you found it".

2. If you do have such a shutdown, ensure that everything is indeed being shutdown correctly.

Sorry I can't be more specific.