C# windows service shutdown event

After I dismissed this window, the status of my service in the SCM changed to Stopping , and I noticed that the service continued to run in Task Manager. After the sleep elapsed nearly 6 minutes later , the process stopped. Refreshing the SCM window showed the service was no longer running.

I take a couple of things away from this. First, OnStop should really attempt to stop the service in a timely manner just as part of playing nice with the system. Second, depending on how your OnStop method is structured, you could force the service to ignore a preemptive request to stop, instead stopping when you say so.

This is not recommended, but it appears that you could do this. As to your particular situation, the thing you have to understand is that the System. Elapsed event fires on a ThreadPool thread. By definition, this is a background thread, which means that it will not keep the application running.

When the service is told to shut down, the system will stop all background threads and then exit the process. So your concern about keeping the processing going until it is finished despite being told by the SCM to shutdown cannot occur the way you've got things structured currently.

To do that, you'd need to create a formal System. Thread object, set it as a foreground thread, and then use the timer to trigger this thread to execute as opposed to being done in the Elapsed callback. All of that said, I still think you'll want to play nicely with the system, which means timely shutdown of the service when requested to do so.

What happens if, for example, you need to reboot the machine? The method provides a parameter command which holds the command code. So to handle the pre-shutdown notification we need to check whether the command matches with pre-shutdown notification code. Toggle navigation Sivachandran Paramasivam. FOSS Contributions.

Enabling pre-shutdown notification If we are developing a Win32 application it is really easy to enable pre-shutdown notification.

GetField "acceptedCommands" , BindingFlags. If you service design requires that you differentiate between ending of service due to shutdown or reboot, the design might be faulty. There is no reliable way to differentiate between the two.

After all a user could just power down via ACPI event pressing the power button at the start of the boot sequence. And now a reboot turned into a shutdown. Or what if a update breaks the boot routine, resulting in it not restarting no mater how hard it tries? You should always asume that every time the windows shuts down, it will stay shut down.

If you service only saves on stuff like shutdown, there is a serious design problem. After all what if the windows crashes or the user pulls the power cord? If you service works with the network, the network connection might terminate at any moment. Your service must be designed around those possibilities.

But again, intention of reboot does not mean a guaranteed reboot. This service does a few functions and one of them is to advise users when Windows is shutdown or restarted. I know the big red button press can't be captured but that should not happen under normal circumstances.

Under normal circumstances of course there would be no reason to have a Windows Form since Services no longer run in the same session as the desktop and AFAIK it isn't supported.

Why are you writing custom code to set the shutdown flag and handle the command specially? For a regular service set CanShutdown to true and then override OnShutdown. This gets called when the OS triggers the shutdown process. If that doesn't work then post the code inside the shutdown method.

Note that if the OS has started shutting down then you are limited in what you can do because the order in which services are notified is undefined. So if you're trying to do something like use the debugger, call a WCF service, etc then there is no guarantee those components will still be running.