The Service Control Manager

Services & background infrastructure described what a service is. This chapter is about the one process responsible for actually making them exist: services.exe, universally known as the SCM (Service Control Manager).

Where configuration comes from

Every installed service has an entry under HKLM\SYSTEM\CurrentControlSet\Services, covered in more depth in Hives, keys, and values. Each key records what the SCM needs to bring that service to life:

• ImagePath — the executable (or, for a hosted service, the host process plus which DLL to load).
• Start — the startup type: Boot, System, Automatic, Automatic (Delayed), Manual, or Disabled.
• DependOnService / DependOnGroup — other services or load-order groups that must already be running.
• ObjectName — the account the service runs as.
• FailureActions — what to do if the process exits unexpectedly.

The SCM's entire job at boot and at runtime is reading this data and turning it into decisions.

Startup order is a dependency graph, not a list

Boot- and system-start drivers load earliest, directly coordinated with the kernel's own initialization (see Startup & shutdown for where this fits in the wider boot sequence). Once the kernel signals that it's ready for user-mode services, the SCM works through everything marked Automatic, but not in registry order — in dependency order, using a topological sort over each service's DependOnService/DependOnGroup list. A service that depends on the TCP/IP stack simply cannot start before it, and the SCM enforces that by construction rather than by hoping installers got the registry entries right.

Delayed Auto-Start exists specifically to relieve boot pressure: services that are important but not needed in the first seconds after logon (many Windows Update or telemetry-adjacent services, for instance) are marked to start a short while after the automatic-start wave finishes, so the machine becomes interactively usable sooner.

The control protocol

Once a service is running, the SCM is also the switchboard for controlling it. Callers — services.exe's own UI, sc.exe, PowerShell's Get-Service/Start-Service, or another service — send control codes over ALPC/RPC: SERVICE_CONTROL_START, _STOP, _PAUSE, _CONTINUE, plus custom codes a service can define for itself. A well-behaved service registers a control handler that responds to these codes and reports its own state back (SERVICE_START_PENDING, SERVICE_RUNNING, SERVICE_STOP_PENDING, and so on) — which is exactly the state machine Services.msc's status column is showing you.

Recovery: what happens after a crash

FailureActions lets a service declare, per-failure-count, what the SCM should do: restart immediately, restart after a delay, run a specified recovery command, reboot the machine, or take no action. The SCM tracks a rolling failure count with a configurable reset period, so a service that crashes once after weeks of stability is treated differently from one crash-looping every few seconds — the latter typically hits a "take no further action" clause specifically so a broken service doesn't spin the machine into a restart loop forever.

A common mistake

Treating startup type as a strict guarantee of when a service starts, rather than a statement of policy, causes real confusion. Automatic does not mean "starts at a fixed point in boot" — it means "the SCM will start this once its dependencies are satisfied, as part of the automatic-start wave," and the actual wall-clock timing shifts with hardware speed, disk contention, and how many other automatic services are queued ahead of it. Two boots of the same machine are not guaranteed to start services in identical wall-clock order, only in dependency-consistent order.

Where this connects

• Service hosts covers what happens after the SCM decides a service should start, when that service is implemented as a DLL rather than its own standalone executable.
• The Configuration Manager is what actually serves the SCM's registry reads — the SCM is, in this sense, just one particularly important consumer of the registry.
• ALPC & local RPC carries every control request described above.