LabVIEW as a Service - process stays in memory despite finishing execution

Question

I have a fairly interesting/unique problem with trying to run a LabVIEW built executable as a service using srvstart (http://www.nick.rozanski.org.uk/services). Srvstart allows you run any application as a service (similar to srvany or firedaemon) but it has the advantage that when you shutdown the service, you can set it to send a WM_CLOSE message which can be picked up in LabVIEW using the Application Instance Close? filter event and shutdown the service gracefully without killing it (as is the case with srvany).
To debug this, I put a simple file write into the Application Instance Close? and Panel Close? events, my 'Exit' case and in a sequence structure at the very end of my application. If the application shuts down gracefully, a file will be created for at least the 'Exit' case and the the final file write.
When I run the application in the LabVIEW development environment or as a normal executable (by double clicking on the EXE), it shuts down gracefully (by queueing up an 'Exit' command and executing the 'Exit' case) when I close the front panel (which is just an empty front panel - no controls/indicators as it runs without a UI as a service) - it creates the files and the application closes (and the process in task manager disappears).
When I run the application and try to shut it down by using 'End Task' or run the application as a service. This should fire the Application Instance Close? filter event, which is then discarded (with silent shutdown) which will should queue up an 'Exit' command and shut down the software gracefully.
What actually happens is that If I'm running the EXE normally and I 'End Task', the front panel closes but the application process stays in the system (i.e. in task manager). None of the files are written so the application hasn't gracefully shutdown. I then have to kill the process in task manager.
When I'm running as a service and 'Stop' the service, the files for Application Instance Close?, my 'Exit' case and the last call get created, the memory usage goes from 30to 80mb and the process stays in memory (in task manager) - the service doesn't respond and I have to shut it down via task manager. I call 'Quit LabVIEW' right at the end of my VI, just after the last call file is created, if I disable this, the same thing happens but the memory usage doesn't go up. In both cases though, the service/application doesn't respond.
I have to be a little careful about what I post in terms of VIs/screenshots for IP reasons but I'll try to illustrate my setup:
In terms of other considerations, the VI does some asynchronous calls for handling TCP connections but these will finish execution when the main event queue is destroyed and the problem still occurs even if no TCP connections occur (and hence no calls are made to the asynchronous VI). I'm running LabVIEW 2011 SP1 on a Windows 7 64-bit.
I tried to use the Desktop Trace Execution toolkit to help debug the issue but it seems that the VI Server shuts down and doesn't show me any trace information after I tell the service to Stop.
The things I don't understand are:
- If I 'End Task' on the EXE, shouldn't that fire the Application Instance Close? filter event in LabVIEW? I understand that Windows would give a 'This application is not responding...' message if it then didn't shutdown or if I didn't discard the event but I don't understand why that event isn't being captured/discarded on my EXE.
- Why doesn't the process end when the VI has finished executing - even though I call the 'Quit LabVIEW' VI as the last call in my application?
- Finally, why does the memory usage go from 30mb to 83mb depending on whether or not I call the 'Quit LabVIEW' VI (but the process still stays in Task Manager)?
The key one is the second one - as this is the one that stops me from being able to stop/restart the service from 'Services'. I'd like to be able to use my 'Exit' case to try and send a last ditch 'Hey I'm shutting down now' message before the PC switches off by gracefully shutting down my service (and you know - because it's better to shutdown things in a controlled manner - hence the reason for using srvstart in the first place!)
If anyone can help shed some light on this I'd really appreciate it as I've been trying to debug this for a lot longer than I'd like and despite asking around a few people not been able to come to any sort of solution.
Certified LabVIEW Architect, Certified TestStand Developer
NI Days (and A&DF): 2010, 2011, 2013, 2014
NI Week: 2012, 2014
Knowledgeable in all things Giant Tetris and WebSockets

Answer 1

Since about LabVIEW 8.5 it is a very bad idea to add the Application Close? filter event and expect LabVIEW Quit to still do anything! It simply behaves as No Operation when this filter event is registered in any event structure.
The proper way to handle this is to make the LabVIEW code terminate gracefully (terminate every loop in there) and as last operation close the Front Panel explicitedly with the VI Server method.
LabVIEW Quit is btw. anyhow only a emergency bandaid. It is really analogous to crashing your car in a wall to make it stop. Pretty effective but also dangerous for various reasons. The proper way to terminate a LabVIEW built application is and has always been to make sure every loop has terminated and then close every and any front panel of your application as last measure. An open front panel (even when hidden) will keep your executable alive forever.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions