Section 4: Service Dependencies

The Big Picture: You Cannot Paint a Wall Before It Is Built

A painter cannot start until the builder has finished the wall. The builder needs the electrician to have run the cables first. Each job depends on an earlier one.

Services are the same. A service that sends data over the network cannot work until the networking helper is running. If the SCM started them in the wrong order, the first one would fail. So each service can list the services it needs. These are its dependencies.

4.1 Dependency Chains

What it is: A dependency means: "service A needs service B to be running first". If B needs C, and C needs D, you get a chain.

Where it is written. In the registry value DependOnService inside the service's key (Section 2.2). It is a list of service names. There is also DependOnGroup for groups of services (older style, used mostly by drivers).

See it in services.msc. Double-click a service and open the Dependencies tab. It has two boxes:

See it in the command line:

sc qc Spooler

Look at the DEPENDENCIES line. For PowerShell:

(Get-Service Spooler).ServicesDependedOn
(Get-Service Spooler).DependentServices

The first shows what it needs; the second shows who needs it.

A sample chain (names vary by Windows version, so check your own PC):

 Print Spooler
      │ needs
      ▼
 Remote Procedure Call (RPC)   ◄── a very basic service most others need
      │ needs
      ▼
 DCOM Server Process Launcher, RPC Endpoint Mapper

RPC stands for Remote Procedure Call. It is a way for programs and services to ask each other to do work, even across the network. Because so much uses it, RpcSs is one of the most depended-on services. It cannot be stopped safely.

Two kinds of arrows:

The SCM follows the whole chain, direct and indirect.

4.2 Start Order Resolution

What it is: When the SCM starts services, it must work out a safe order. This is called resolving the dependencies.

How it behaves:

1. The SCM looks at which services must start (Automatic ones at boot, or the one you asked for).
2. For each, it first checks its dependencies. If one is not running, the SCM starts that first, even if it is Manual.
3. It waits until the dependency is running (reports its status, Section 9) and only then starts the dependent service.
4. It repeats this down the chain until the first service has nothing it needs.

You ask:  start A          A needs B,  B needs C

 step 1   SCM sees A needs B   → look at B
 step 2   SCM sees B needs C   → look at C
 step 3   start C   (C has no needs)
 step 4   C is RUNNING → start B
 step 5   B is RUNNING → start A

Services without dependencies can start together. The SCM can start unrelated services at the same time to save boot time. Order is only forced where one needs the other.

Things to know:

Real-world analogy: a to-do list where each task shows "do this first". The manager works from the bottom of the list upwards.

Try this (read-only):

Get-Service | Where-Object { $_.ServicesDependedOn.Count -gt 0 } | Select-Object -First 8 Name, @{n='Needs';e={($_.ServicesDependedOn.Name) -join ', '}}

4.3 Failure Propagation

What it is: When one service fails, the failure spreads to the services that depend on it. This is called failure propagation.

What happens at start time. If B cannot start, then A (which needs B) cannot start either. The SCM stops trying and reports an error:

What happens while running. If B stops (it crashes, or someone stops it), Windows must also stop A, because A would no longer work. So stopping B stops all its dependents. (Starting B again does not always restart A. That depends on A's own recovery settings, Section 7.)

        Normal                           B crashes
   C ─► B ─► A   all RUNNING         C ─► B(X) ─► A
                                           │         │
                                           ▼         ▼
                                     B stopped   A stops too

Why this causes confusing problems. You may see the error message about A, but the real fault is in B or C much further down the chain. Always follow the chain down to the root:

1. Note the service that failed.
2. Open its Dependencies tab (or sc qc).
3. Check each dependency's state.
4. Start with the deepest one that is not running, and find out why (Section 8).

Good habits:

• Before stopping a service, check who depends on it.
• Never set a service to Disabled without checking its dependents.
• When one service will not start, look at its dependencies first.

Windows tip: In services.msc, a service whose dependency is disabled will show an error dialog such as "The dependency service or group failed to start" when you click Start. That message is the 1068 error.

Summary