Every once in a while a question pops up about Windows Installer trying to start a service and if fails but that if the user starts it manually it works. The solution usually turns out to be related to solving some race condition either in terms of dependency or timing. I won’t attempt to enumerate all of these today but I did want to draw attention to something I recently observed.
The Windows (NT) Service Control Manager ( SCM ) waits up to 30 seconds by default for a service to report that a pending operation is successful. There is a registry value called ServicesPipeTimeout that can be used to change this behavior to a longer time. In doing so though one must keep the following in mind:
- As with many things ServiceControlManager related, the ServicesPipeTimeout setting requires a reboot to become effective. It’ll offer no help if you are trying to start a service during the install.
- Even if it was effective right away, I’ve observed that when the MSI SDK says “max 30 seconds” it means 30 seconds max. Changing the ServicesPipeTimeout setting has no effect on the behavior of the StartServices standard action. ( A bug in my opinion. MSI should track with SCM in my opinion. )
Now personally, I think it would be a mistake for an installer to set ServicesPipeTimeout. This is the sort of system wide setting that I usually shy away from out of fear of causing unforeseen side effects. However, I am interested in knowing if any of my readers have experience with this setting and how things turned out for them.
So in conclusion, a setting exists but it won’t help with the installer much unless all you need to do is set the service to automatic and ask for a reboot.
For C#/.NET junkies using the ServiceBase class, I’ll offer an additional observation that thread.Sleep() calls in the OnStart() method exceeding the ServicesPipeTimeout threshold didn’t seem to cause any problems. However placing the delay in the constructor or instance members in the class did cause a problem.