Exiting the RTE

[j_meier]

Hi there:

I have an issue here that has me stumped: I can not completely exit an application when it is built in a executable and running with the Run-Time Engine unless the development system is also installed.

Full story:

- The application should close when the user clicks on a "Exit" button.

- An event sructure catches this value changed event, closes all running loops, i.e. shuts down hardware, saves the vi configuration and exits.

- To close the built executable I execute the "Quit Labview" vi, with the boolean input set to true if the vi is not executed under the development system.

- I have now added some dignostic code around this, an indicator to see if the bool is truly true, and a delay to keep the window open to see it.

- From this I know that with the RTE the "Quit Labview" vi is called with a TRUE input, and it should close everything (the vi and the RTE)

- The "Quit Labview" vi is the last vi in my code, this was verified by tracing the execution in the development system (Labview 2011 SP1).

- On MY computer this works, in the development system and with the built application.

- On a second computer that has the development system and the RTE installed it works, too.

- On a computer that has only the RTE installed the window of my application closes, but the application remains in memory, as seen in the windows task manager. I have to kill it there.

- If I use HideRootWindow = False in the ini file of the executable the RTE root window survives in the taskbar.

- This last computer is fresh out of the box, has a clean installation of the OpSystem (XP, don't ask why) and only the RTE and Labview drivers installed to execute this one application.

- The RTE was installed with an installer created for this application, on my computer, pulling the installers out of the cache created during the installation of Labview on my computer.

I'm lost in two ways now:

- I don't know why this does not work on the computer without the development system.

- I don't know how to debug this.

Due to the commercial nature of the project I can not post the code here - hopefully my description is enough to understand the problem.

Any hints would be greatly appreciated.

Ciao,

Joachim

[asbo]

Easy answer: instead of calling Quit LabVIEW, use System Exec to run "taskkill /f {appname}.exe".

Hard answer: break down all of the technologies (DAQ, TCP, Shared Variables, etc) you use and figure out which one isn't shutting down properly. You failed to mentioned the version of LabVIEW you're using but I'll assume it's LV2011. Try turning off SSE2 optimizations in your build.

[Slacter]

Have you tried using the VI Properties >> Window Appearance >> Custom "Show front panel when called" and "Close afterwards if originally closed" checkboxes on your top level VI? If this isn't desirable, how about trying the FP.Close invoke node upon exiting?

I personally would avoid the Quit LabVIEW VI. I don't find it to be a gracious way to shut down an application. Letting the top-level VI complete its execution and closing afterwards is smoother.

[Rolf Kalbermatter]

I can only echos slacter's recommendation. I have never used the Quit LabVIEW primitive in my 20 years of LabVIEW programming, other than to try it out. In the development environment I don't want to quit LabVIEW normally anyhow, and in a built application, the executable terminates as soon as you close the last front panel. So this is usually what I do as last thing in my main VI after all loops have exited.

[j_meier]

Thanks to everyone for the suggestions - problem is that they didn't solve the problem.

What I tried:

- remove "Quit Labview" and replace it with a "Close Front Panel"

- remove Splash Screen and start Main app directly.

- deactivate SSE2 optimization

- comment out all code calling dlls or hardware drivers

- comment out ALL code

Now I have an application that displays a front panel and a start button on the toolbar. Which does nothing, of course.

I can now go to File->Exit and close that window. Guess what, on a computer with DevSystem my "application" goes out of memory (true for all edits to the code I tried), on the one with only the RTD the window disapears, the entry in the task manager stays. Specifically, if I don't hide the root window with the .ini file, I can actually observe how the application windows disapears for a moment before a new window shows up in the taskbar. I believe this is this root window, it doesn't display if I select it.

What is this "root window" for, anyway? A place for the RTE to live in?

I'm now going to implement the "taskkill" suggestion to give our users something to work with and have a chat with the folks from NI.

General comment: For years now I was living under the impression the "Quit Labview" vi is intended to shut down the RTE (Who needs to shut down the dev system?). Thats why I thougth it had this boolean input (RTE or not?). It always worked, I never questioned it...

Thanks again,

Ciao,

Joachim

[Rolf Kalbermatter]

Quit LabVIEW existed long before LabVIEW allowed to build executables. As such it's intention was for sure not to be used for executables in the first place. And exactly because of that there was a way to shutdown the entire IDE, as any experiments were executed in the dev system, since that was the only way to execute VIs. So if you wanted to build an experiment that was shutting itself down completely after execution you had to have a way to exit the dev environment too.

With the advent of the application builder and the ability to create executabls, the Quit LabVIEW node got pretty much obsolete but wasn't a big enough legacy burden to be really removed.

The root window is a hidden window that handles all the message interaction with the operating system. That is a LabVIEW speciality to implement a Mac OS functionality where system OS messages are always sent to the root loop of a process. So they created a hidden root window which does this root loop handling on Windows, such that the rest of LabVIEW messaging could stay pretty unchanged from the code used for Mac OS

There is a ini setting hideRootWindow=True that you can add to your executable ini file to make the root window button not appear in the taskbar, although I'm not sure that should be still necessary in recent LabVIEW versions.

As to your problem, it pretty much looks to me like a corrupted installation of the runtime system or some driver you are accessing in your appllication. Do you access any hardware in your app? Or ActiveX components or DLLs? Any of these could cause this problem if you don't properly close any an all resources that you open up during application lifetime. LabVIEW has no way to force a DLL or ActiveX out of memory if that DLL thinks it still wants to stay in memory because a resource it provides hasn't been closed properly.

[j_meier]

Quit LabVIEW existed long before LabVIEW allowed to build executables. ..

Interesting how things change...

I see now that I don't need it, but as cause of problems it got eliminated, too.

As to your problem, it pretty much looks to me like a corrupted installation of the runtime system or some driver you are accessing in your appllication. ...

The answer to this will depend on this question: If I draw the diagram disable structure around all of my code, does Labview still load driver, dlls or .net assemblies in memory and starts them enough to allow them to hang? I hope not!

Assuming it doesn't, I'll download a (hopefully) clean version of the RTE and install it on my test computer.

The taskkill solution does work. For now this gives us something we can work with, but it has to go, the sooner the better.

[j_meier]

Just for the record, in case someone runs in the same issue:

- I uninstalled everything NI-related from the computer showing the problem

- During uninstallation some NI-services refused to shut down (webserver-related). Had to kill then manually with the task-manager.

- After installation of the latest RTE and drivers from the NI website the issue is gone.

Now I only have to figure out if my local installer cache is corrupted and propagated the corruption to the installer I built. I fear a new installation of Labview will be necessary to make sure I build working installers...

Thanks again to everyone!