Running a LabVIEW executable as a Windows service

[d.manzenberger]

It seems this comes up once a year, but I haven't found any current "How-to" for the following:

How do I run a LabVIEW executable as a Windows 7 (or Windows 10) service?

All I have are:

A page that no longer exists: 

http://members.cox.net/kuanchen/lvservice/index.html

A topic that has been archived, and doesn't appear to apply to Win7: 

http://digital.ni.com/public.nsf/allkb/21BA0F671A63A60386256CB4004DF99B

A paper that has been moved:

http://www.ni.com/white-paper/3185/en/

http://zone.ni.com/devzone/cda/tut/p/id/3185

And a service that costs $50:

FireDaemon

Any good (current) How-to's I can look at or knowledgeable people I can talk to? 

[cbutcher]

This response on Stack Overflow lists ways to create a Windows Service for a generic executable - one using a service manager application and another using some sort of command line tool to install an application as a service.

I took a quick look at nssm and it seems simple enough to use but my attempts at building a quick test application for use as a service don't seem to have worked as I'd have liked - the service started but then didn't visibly do anything.

My guess is your service took more than 30 seconds to write, and so probably will work better!

I took a more significant (although not by much) swing at this and created an executable that logs the time to a file. When I started the service, time was logged. When I stopped the service, it stopped. I'm sure I probably stopped the service with the equivalent of the LabVIEW Abort button, but it worked well enough for me.

My test project is attached. (It's LV2017 - sorry if this isn't very helpful, but the application really doesn't do much anyway.)

[d.manzenberger · Accepted solution]

I found this late Friday night, right before I called it a day:

https://www.howtogeek.com/50786/using-srvstart-to-run-any-application-as-a-windows-service/

Following the process outlined gave me a "error 1067: the process terminated unexpectedly."

I fixed this by replacing this step:

"SC CREATE <servicename> Displayname= "<servicename>" binpath= "srvstart.exe <servicename> -c <path to srvstart config file>" start= <starttype>"

with this:

"srvstart.exe install <servicename> -c <path to srvstart config file>"

Now my program runs even though no-one is logged in 😄

[d.manzenberger]

And for future generations, the process is this:

Get this package:
srvstart_run.v110.zip

and put the contents into any folder that appears in your %PATH%

It should be four files: logger.dll, srvstart.dll, srvstart.exe, svc.exe

Create an ini file and put it somewhere easy to type the full path. Inside put this:

[<servicename>]
startup="<path to executable file>"
shutdown_method=winmessage 

shutdown_method can also be kill (which is what I ended up using).

This ini file will be your "srvstart config file"

Then run the following command as Administrator:

srvstart.exe install <servicename> -c <path to srvstart config file>

In all of the above commands and files, replace <servicename> with the name of the service you are creating (must all be identical), and replace <path to...> with the appropriate path i.e. C:\...\...

[ian.yeager]

Perfect post, one quick question.

Any thoughts on best practice managing the shutdown of a service that runs without a UI or Notification Bar interaction? I'm creating a thin-client that launches as a service and exists with zero interaction with the user. How can I capture the shutdown event that comes from Windows when you shutdown a service?

[d.manzenberger]

I still haven't been able to get LabVIEW to accept the shutdown signal from Windows. I suspect that the way that I set up the service is the problem, that it doesn't have all of the hooks from Windows that it needs.

Perhaps some sort of shutdown client that sends an external signal (through tcp or udp, perhaps) to shut down? I have just ruggedized my application against ungraceful shutdowns by preserving any required running memory in a database or in the devices I am connected to. It's not pretty, but Windows will assertively kill all child processes for you :cringe:

[ian.yeager]

Yeah, that's my worry. My application is running a TCP/IP server so the threat of hanging ports concerns me.

[d.manzenberger]

I wonder if the "SC CREATE" procedure adds the correct communications with Windows. I was unable to get it running, but that doesn't mean it isn't possible. Unfortunately we're in the home sprint on my current project, so I'm unable to divert time to try again right now.

[ian.yeager]

I guess Windows doesn't care, per their article;

https://msdn.microsoft.com/en-us/library/windows/desktop/ms685149(v=vs.85).aspx

"Because the computer is being shut down, do not spend time releasing allocated memory or other system resources."

I guess a hanging port would be recycled on shutdown anyway and any clients would see the connection lost so it's not that big of a deal. I may play around with both methods you mention and see if I can't get some resolution, but probably won't put too much effort into it.

Thanks for the good write-up.

[majoris]

The way I did this was to modify the following library to capture the close / shutdown signals and not pass them through (doing so didn't trigger the event structure close events, so I could never gracefully shutdown) but instead send my own signal to Labview (such as an event or notification).

http://www.ni.com/example/29394/en/

I use NSSM by the way which lets you customize the shutdown signals and how long each signal will wait until timeout.

I can't provide the modifications, but my recommendation is to modify the library to monitor the signals (try for instance, outputting them to a log file). Then, change the code so that it captures those signals and gets rid of them and then send Labview a signal through the library to gracefully shutdown.