2

I have a somewhat strange case to deal with...

  • I have Windows Service "A".
  • "A" is monitored for events in "B". "B" is an application that will restart "A" if "A" stops running.
  • "A" should not be restarted if the user manually shuts "A" down from the Services app in Windows, or from the command prompt using a net stop on it. Basically, whenever a non-application (i.e. human) stops it, I don't want it to restart "A".

Here is a simple example of "B":

ServiceController controller = new ServiceController(someServiceName);
while (true)
{
    controller.WaitForStatus(ServiceControllerStatus.Running);
    controller.WaitForStatus(ServiceControllerStatus.Stopped);
    controller.Start();
}

Since a user will cause the service's status to invoke a stop the same way another application will, is there any way to detect who actually stopped that particular Windows service? Is there a way to detect if an actual person stopped that particular service?

Alexandru
  • 12,264
  • 17
  • 113
  • 208
  • 1
    Perhaps this will be helpful... http://stackoverflow.com/questions/496632/is-it-possible-to-log-who-started-or-stopped-a-windows-service – eddie_cat Jul 17 '14 at 14:08
  • What scenarios are you specifically trying to deal with? You say you want to allow manual shutdowns to work, and there's already facilities built in to restart services if they fail, so what's the actual usecase here? – Damien_The_Unbeliever Jul 17 '14 at 14:41
  • @Savanna I'm not sure if querying the last service account that stopped it would work since an Administrator command prompt could net stop the service. Yet, a human is still the one who is using that command prompt, and it would not be possible to distinguish that with another administrator application stopping the service account (which I would invoke a service restart). Also, from testing, I saw that event logs (Windows 8.1) don't contain any User data for me. Nothing in the System logs, and the Application logs have "Service started successfully." with the User as N/A. – Alexandru Jul 17 '14 at 14:51
  • @Damien_The_Unbeliever From testing, I tried setting a 0 second start delay on my service and have it restart on all failures, and was playing with the logic here, having it restart when I kill the host process in Task Manager. I'm not entirely sure how its implemented in the OS but the logic is faulty. I can start a service, and kill the host executable in Task Manager, and keep killing it as it comes up, and even though its set to restart it actually stops working at some point (maybe a race condition while killing on a restart when it is in the start->started transition). – Alexandru Jul 17 '14 at 14:53
  • Does B do anything other than ensure that A is running? You could just have the user kill A and B if the services needed to be stopped and not restarted. It's a bit hard to say what your options could be without knowing how your applications will be used. – eddie_cat Jul 17 '14 at 14:54
  • @Savanna B ensures that multiple other services are up, so the idea was to find a creative/transparent way to get B to not restart A if a human wants to stop it. Transparent in the sense that I don't want the human to have to go in and set an option somewhere to tell A not to restart the application while some flag is set, but that may be the only option. – Alexandru Jul 17 '14 at 15:01
  • Another option I could think of would be to have your users use your own application to stop A if they want it to be stopped, and have that application set such a flag so the user wouldn't have to. This would work better if you could use B for it, which is why I asked before if users could use B to stop A. But it seems like B is also a Windows Service, so you'd need something totally separate. ANd then you'd still have the possibility of users stopping A via other methods and having it continue to restart. – eddie_cat Jul 17 '14 at 15:04
  • @Savanna Yes, B has a front-end application I could use to signal it. That is an option for sure. I was trying to see if there was a more transparent way of doing it. Like you said, the problem with the front-end application approach is that it would become the *only* way of doing it. – Alexandru Jul 17 '14 at 15:08

0 Answers0