Windows services not starting automatically?

We've had some nasty time sync problems on our Windows Server 2008 R2 servers lately.

I traced this back to something very simple: the Windows Time Service was not started! The time can't possibly sync via NTP when the time service isn't running...

The Windows Time Service was set to start "automatically" in the services control panel, which I double and triple checked. I also checked the event logs and I didn't see any service failures or anything like that. In fact, it looked a heck of a lot like the Windows Time Service never started up automatically after the weekly Windows Updates were installed and the servers were rebooted. (this is set to happen every Saturday at 7 PM.)

The minute I started the Time Service, the time synced fine.

So, then, the question: why would a service set to start "Automatically" ... not be started automatically? That seems sort of crazy to me.


W32time will not start automatically if the PC is not in a domain. Damn Microsoft!

Try to run this: sc triggerinfo w32time start/networkon stop/networkoff


One possible explanation, from this thread:

The way I understood it, basically the service won't be turned on until you or a task or a piece of hardware or network, start an event to turn it on. When you try to update the time, you call on the service and trigger the event 'Start xyz service'. It can also turn the service off when finished. That's very simplified. It is one reason why seven is faster, because many services are only running when needed instead of running all the time waiting for something to use them. In effect you don't have to try to decide which services you need or don't, they can take care of themselves.

He's talking about the new kernel in Windows 7.

Since Windows Server 2008 R2 and Windows 7 do share the same kernel, I wonder if the resolution is the same?

They recommend setting the service to automatic/delayed start to fix this.

I still maintain it's downright insane that a service set to automatic wouldn't be started ... and I don't fully understand the semantic difference between a delayed auto-start and an auto-start, but if it works, I guess I won't complain.


Unfortunately with windows time you have manually turn on logging.

There is no good answer to "what would cause a service to not start automatically." The only real reason is that a dependency did not start correctly, or there was some sort of crash in the service when it started. And without logs, well your guess is as good as ours.

I would suggest turning on windows time logging for the next couple of patch cycles. If the service comes up you're all good, if it doesn't you have something to work from.

Just as a note, I have seen more than once services decide to just not start for no good reason after a patch, but work just fine after that first reboot.


Started to write a comment, then ran out of space.

You would actually get some information from this log.

  1. If there is no log at all, it's not even trying to start. And you can start researching from there, every little scrap of info helps on these types of problems.

  2. Since it's a debug log you are turning on with the above link you should get something if it tries to start. You'll at least have a better idea of why it is failing to start successfully.

You've discovered one of the great pains of being a sysadmin: You need logs to tell you where to start looking, but the service isn't getting to a point that it can generate logs. A classic chicken and the egg problem.