A Windows service fails to start with "Error 1053: The service did not respond to the start or control request in a timely fashion." What does the Service Control Manager expect from a service process, and where do recovery actions fit in?
answer
- the SCM expects to be told, not to guess
- thirty seconds to say hello
- start-pending with a moving checkpoint
- a console app is not a service
- recovery is for after it was running
basics
~20 sError 1053 means the process never reported back to the Service Control Manager in time. A service must connect to the SCM and report its status within roughly 30 seconds, reporting start-pending with a wait hint if initialisation is slow — an ordinary console program run as a service always fails this way.
solid answer
~60 sThe SCM does not just launch a process and watch it; it expects a conversation. The process must connect to the SCM and register its control handler within about 30 seconds of launch, then report `SERVICE_START_PENDING` with a wait hint while it initialises, and finally `SERVICE_RUNNING`. If it stays silent past the timeout, the SCM kills the attempt and reports 1053. The overwhelmingly common cause is a normal application deployed as a service with no service plumbing at all, or one whose initialisation — a database connection, a certificate fetch — blocks past the timeout without ever reporting progress. The fix is to report `SERVICE_START_PENDING` with an increasing checkpoint and move slow work off the start path, not to raise `ServicesPipeTimeout` globally, which slows every service's boot failure. Recovery actions are a separate mechanism: they tell the SCM what to do after a service that *had* started dies — restart it, run a program, or reboot — and by default they only fire on abnormal termination, not on a clean exit or an administrative stop.
code
powershell · 8 lines# What the SCM itself recorded about the failed start
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'} -MaxEvents 20 |
Select-Object TimeCreated, Id, Message
# Inspect and set recovery behaviour
sc.exe qfailure MyAppSvc
sc.exe failure MyAppSvc reset= 86400 actions= restart/60000/restart/120000/restart/300000
sc.exe failureflag MyAppSvc 1go deeper
Know that a Windows service must be written to talk to the Service Control Manager, and that 1053 means it never reported its status in time — not that the file is missing.
Explain the handshake: connect to the SCM within about 30 seconds, register a control handler, report start-pending with a wait hint and advancing checkpoint, then running. Distinguish 1053 from 1067, 1069 and dependency failures.
Show the diagnosis path — SCM event-log entries, running the binary interactively, checking ImagePath and the account — and argue for fixing status reporting instead of raising the machine-wide timeout. Know that recovery fires only on abnormal exit by default.
Own the operational contract: what readiness means for a service, how crash loops are surfaced rather than absorbed by restarts, and what restart delays and failure-count windows are standard across the estate.
## The start handshake A Windows service is not merely "a program the SCM launches". It is a program that speaks a protocol: 1. The SCM creates the process from `ImagePath` and waits. 2. The process calls `StartServiceCtrlDispatcher`, which connects it to the SCM and hands control to the service's entry point. **This must happen within the SCM's connection timeout — 30 seconds by default.** 3. In its `ServiceMain`, the service calls `RegisterServiceCtrlHandler` (or `RegisterServiceCtrlHandlerEx`) to receive stop, pause and shutdown notifications. 4. It reports `SERVICE_START_PENDING` via `SetServiceStatus`, with a `dwWaitHint` that says how long it expects to need and a `dwCheckPoint` it increments as it makes progress. 5. When it is ready, it reports `SERVICE_RUNNING`. Miss step 2 and you get 1053. Reach step 4 but then let `dwWaitHint` elapse without incrementing `dwCheckPoint`, and the SCM concludes the service has hung and gives up the same way. ## Reading 1053 correctly The error is about *silence*, not about crashing. Distinguish it from its neighbours: - **1053** — no status reported in time. Usually missing service plumbing, or blocking initialisation. - **1067** — the process terminated unexpectedly. It started and then died; look for an unhandled exception at startup. - **1069** — logon failure. The service account's password, state, or missing *Log on as a service* right. - **1075/1068** — a dependency is missing or failed to start. So when 1053 appears immediately rather than after 30 seconds, the process is often exiting instantly — a missing runtime, a bad working directory, or a `.NET`/runtime version mismatch — and the SCM reports the timeout error because it never got a status either way. ## Diagnosing it Run the binary interactively from an elevated prompt first: a real service refuses to run that way with a distinctive error, which is itself informative, while a plain console app runs happily — proving it has no service plumbing. Then read the System event log for the SCM's own entries (source *Service Control Manager*), and the Application log for the process's unhandled exception. Check `ImagePath` for an unquoted path with spaces, a stale working directory assumption, or a relative path. ## The timeout knob, and why to leave it alone `HKLM\SYSTEM\CurrentControlSet\Control\ServicesPipeTimeout` is a `REG_DWORD` in milliseconds that raises the SCM's connection timeout machine-wide, and it takes effect only after a reboot. It is a legitimate stopgap on a slow or heavily loaded host, but it is machine-wide: every service now takes longer to fail. The correct engineering fix is for the service to report start-pending promptly and then do its slow work — connecting to a database, warming caches, fetching secrets — either on a background thread after reporting running, or in a loop that keeps advancing the checkpoint. ## Recovery actions are a different mechanism Once a service is running, recovery actions decide what happens if it dies. They are configured per service as an ordered triple — first failure, second failure, subsequent failures — each being *take no action*, *restart the service*, *run a program*, or *restart the computer*, with a restart delay and a *reset failure count after N days* window that puts the counter back to zero once the service behaves. ``` sc.exe failure MyAppSvc reset= 86400 actions= restart/60000/restart/60000/restart/300000 sc.exe qfailure MyAppSvc ``` The subtlety that catches people: by default recovery actions fire only on **abnormal** termination — the process crashed or exited unexpectedly. A service that exits cleanly with a success code, or that is stopped by an administrator, does not trigger recovery. `sc.exe failureflag <name> 1` extends recovery to stops with an error, which is what you want for a service that shuts itself down on a fatal condition rather than crashing. ## The judgment an interviewer is listening for Restart-on-failure is not a fix; it is a way to buy time. A service that recovery restarts every sixty minutes is a service with a leak or an unhandled condition, and the restart is hiding it. Set the reset window and the delays so that a genuine transient recovers silently but a persistent fault becomes visible — a long enough delay that the crash loop does not consume the machine, and alerting on the SCM's own event-log entries so someone finds out that recovery is doing work at all.
- Your service legitimately needs two minutes to warm a cache before it can serve traffic. How do you start it without hitting the timeout?Report `SERVICE_START_PENDING` immediately with a realistic `dwWaitHint`, and keep calling `SetServiceStatus` with an incremented `dwCheckPoint` as the warm-up progresses — the SCM only gives up when a wait hint expires with no progress. Better still, report `SERVICE_RUNNING` once the control handler works and do the warm-up on a background thread, exposing readiness separately from service state.
- A service is stopped cleanly by its own code after a fatal configuration error. Why do the configured recovery actions not fire?Because recovery actions default to abnormal termination only. A clean exit, and an administrative stop, are both treated as intended. Setting the service's failure flag makes recovery apply to stops that report an error exit code as well, so a service that shuts itself down deliberately on a fatal condition still gets restarted.
- When is raising ServicesPipeTimeout the right call?Rarely, and only as a stopgap — on a genuinely slow or contended host where several services legitimately need longer to connect to the SCM. It is machine-wide and needs a reboot, so it also slows down how quickly every other broken service reports failure. Fix the service's status reporting first; treat the registry change as a temporary measure with a ticket attached.
- How would you tell that recovery actions are silently masking a recurring fault?Watch the Service Control Manager entries in the System event log — the SCM logs when a service terminates unexpectedly and when it takes a recovery action. If those appear on a rhythm, the service is crash-looping under cover of the restart. Alert on them, and set the failure-count reset window long enough that repeated failures accumulate rather than resetting between crashes.
The SCM is a dispatcher who radios a crew and expects a check-in: silence for thirty seconds is treated as a failed callout, regardless of how busy the crew actually is.
saying these in an interview costs you the question
- Says 1053 always means the binary is missing
- Raises ServicesPipeTimeout as the first fix
- Thinks any executable can be registered as a service and just work
- Believes recovery actions fire when an admin stops the service
- Treats automatic restart as a resolved incident