Error 1053: The service did not respond to the start or control request in a timely fashion

Last week we had an error while starting a Windows Service on a new Windows 2003 R2 server. The error message said: “Error 1053: The service did not respond to the start or control request in a timely fashion”. The strange thing was that the error popped up immediately. (Normally, this error message does not appear until after a 30-second time-out.) Nothing was logged in the event log.

Since we didn’t find any more information about the error, we decided to start debugging using WinDbg, which is part of Debugging Tools for Windows. (Install “Debugging Tools for Windows” to “C:\Program Files\Debugging Tools for Windows\”. First you need to get your debugger attached.

Since you don’t have the time to attach your debugger after starting the service, you need to attach it right away. The way how to do this, is to use gflags.exe which you can find in the “Debugging Tools for Windows” directory. Click on the tab “Image File” and enter the name of your service. To find the name of the service, go to properties and use the name you find in “Path to executable”. The name to use should be something like MyService.exe. In gflags, enable the “Debugger” checkbox and type “C:\Program Files\Debugging Tools for Windows\ntsd.exe -server tcp:port=1234 -noio”. (ntsd.exe can be found in the same directory, so adapt the path if necessary.) The reason not to use WinDbg directly is because Windows Services don’t interact with the desktop. In stead, we will connect via WinDbg using “Connect to Remote Session…” (On Windows Server 2008, Windows Services also run in a different session, known as session 0.) Before we can start debugging, you should increase the default 30-second time-out. To do this, open your registry (using the Start button, Run…, “regedit) and add the DWORD “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServicesPipeTimeout” and set the value to 86400000, which is the amount of milliseconds in 24 hours… You’ll need to restart the machine before the setting is taken into account.

Now we are ready to debug. Start the Windows Service. You can now run “windbg.exe -remote tcp:server=localhost,port=1234” to connect to the remote session and start debugging.

During my debugging experience, I first issued a “go” command. I saw several assemblies being loaded into memory, so I performed a “Break”. Since the mscorwks assembly was loaded in the meanwhile, I could continue with:
.loadby sos mscorwks
!ca ex
go
(There was a new break on the next exception so now I could start debugging it.)

Apparently, an exception was thrown in the constructor of the class inheriting from ServiceBase, so even before the OnStart was executed. Probably this was also the reason why nothing was logged to the event log…

I’m not sure how to break automatically once the mscorwks assembly gets loaded. I might have been lucky that I was fast enough to perform a “break” manually…

I also noticed that since recently “Debugging Tools for Windows” is part of the Windows Driver Kit (WDK). You can download this as an .ISO file and mount with Daemon Tools. Actually the installer files (.msi) for “Debugging Tools for Windows” are in the debugger directory on this disk…