>That might work but seems (perhaps of necessity) a little convoluted. Haven't looked closely but there are a couple of properties on ServiceBase that might help:
>The RequestAdditionalTime() method in the OnStop() might have some effect.
>There's also a CanShutDown property which will cause the OnShutdown event to fire - although I'm not sure what you can do with it.
>
>There's also a registry setting which can increase the time the SCM will wait for a service to shutdown. See WaitToKillServiceTimeout.
>
>But, at the end of the day, you should still program so that the service can shut down safely and coherently in a short period of time.

That's exactly that. We just cannot afford one single situation that one of our services will be in a middle of a process and subject to a brut force termination caused by a reboot.

Initially, I thought that the service design would have been a little smarter than that. For example, CanShutDown with the event apply. So, I thought that in there we can let it know what we acknowledge the request for termination or activate a property or an event that will interact with the user, but by the usage of the OS. In that case, it would have been possible to let the user know. I had assumed this is what most of the services are doing. I face that situation a lot. Whenever I need to restart the server, I will sometimes receive a message and then it goes off by itself. The restart now continues its restart procedure. But, I would then assume that all those situations are bound to the usage of Local System Account.

I just cannot understand the restriction in the OS that the usage of another account cannot benefit of the interaction. To me, this is also related to the OS infrastructure and something could have been done for that up to where we are today in the OS.

It seems quite obvious that many enterprise product requires one or multiple services to run on a domain account, so to benefit of NAS resources, the network and so on. I just do not understand why we have to go from Montreal to Florida by doing a detour up to Vancouver.

So far, the safest way is a slave service to check it out. But, that is an additional project I would like to avoid to support. Despite the fact that it would be generic and wouldn't change after, it is still one additional project that we have to add in our infrastructure which it wasn't planned.

I have found so far that very limited environment have this need, or not at all, assuming that they would like to have the support but prefer to do as we do now by adding procedures to the network team that any restart of a server requires intervention from the tech team to shut down manually specific services which would then be started manually by them on startup.