Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

On Windows Server 2003, we have an occasional condition where an application service fails to start immediately, and the service stays in the “Starting” state for 20 minutes, after which it times out and shuts down. If this happens on a reboot, then it is not possible to login to the server (even from the console) until the 20 minute timeout has elapsed. This service does not have any dependencies.

Is this normal behaviour, i.e. is it always the case that you cannot login until all automatic services have started or timed out?

Or is this likely to be a peculiarity of this particular application service?

share|improve this question

What you're seeing is likely a peculiarity of your particular service. If the service only acts that way during boot it's going to be a little tough to troubleshoot, but you can use Process Monitor and its boot-time logging capabilities to figure out what's happening with the service.

Any chance you can share what the service is?


My apologies for not following your question initially.

AFAIK, the behaviour you're seeing is normal for the Windows 2003 and earlier Serivce Control Manager. In Windows Vista and up, a "delayed auto-start" service type (SERVICE_CONFIG_DELAYED_AUTO_START_INFO) was added to allow services to start automatically, but delayed. I believe that the behaviour you are seeing is behind the rationale for the new feature in Windows Vista.

share|improve this answer
Hi, thanks for your response. Actually, I know why the service is not starting up immediately, what was surprising me was the fact that you cannot login to the server even from the console until the service either starts or times out. I wondered if that was normal – i.e. does windows have to get all the automatic services started before it will let you login? (The service is an IBM Websphere JDBC Connector and it was waiting to make a connection to a database that had failed). – Stuart Forman Jul 6 '09 at 21:54

It's not normal for the login screen to wait for a service to appear. I would check the dependencies and see if that service made itself a dependent of other, more important services.

Otherwise what could be happening is that the service gets in some loop which kicks the CPU up to 100% and slows winlogon from executing. One way to check is to put the service on manual then start it when you have task manager the CPU load. Also during that time run a ping test to see if it is saturating the NIC.

share|improve this answer

try setting the service to manual then have a script run to start the service once you've logged on ;-)

share|improve this answer

A couple of possibilities (depending on the offending service and what it is doing) would be to check your synchronous versus async startup processes for the system. It's not horribly likely but plausible depending on what sort of interactions the service needs / makes that the logon is just waiting it's turn. The other possibility would be to check the systems timeouts for waiting for network connectivity. Depending on the service and the timeout configs it could just be waiting on connections that will never be established. (One way to test this is if you physically disconnect all network connections does the logon prompt appear quickly at startup)

Otherwise I'd tend to recommend you actually figure out why the service is failing, if it's an instance where the service is able to start after a certain point of startup you might actually be able to resolve your problem by creating a dependency on the service(s) it needs to connect properly. Lastly a situation I've seen with this symptom is where there were problems with the service account being used for the service either connecting to the domain or actual problems with the account itself (lockout etc).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.