Services & background infrastructure

Everything in Level 0 assumed a logged-on user, a window station, a desktop. But most of what keeps a Windows machine actually working — network stack helpers, the update pipeline, security agents, print spooling, remote management — runs whether or not anyone is logged on at all, and keeps running across every logon and logoff. That's what a service is: a long-running background workload managed by dedicated OS infrastructure, not an ordinary app that happens to hide its window.

Not just "an app without a window"

It's tempting to think a service is just a console app someone remembered to hide. The actual differences are structural:

• Lifecycle owned by the OS, not by a user. A service starts because the Service Control Manager decided to start it — at boot, on a delayed schedule, on-demand when something requests it, or in response to a trigger (a device arriving, a network state change) — not because someone double-clicked it.
• A different identity, usually. Interactive apps run as the logged-on user. Services commonly run as LocalSystem, NetworkService, LocalService, or a dedicated virtual service account, deliberately decoupled from any human identity, so that the machine's background functionality doesn't disappear the moment a user logs off.
• Isolated from the interactive desktop. Services run in Session 0, a session with no interactive logon at all, specifically so a compromised or malfunctioning service can't draw UI on, or capture input from, whatever human is using the machine — the same isolation boundary introduced in GUI & windowing.
• A defined recovery policy. The SCM can be told exactly what to do if a service crashes — restart it once, restart it with a delay, run a recovery program, or give up and leave it stopped — none of which has an equivalent for an ordinary application.

Two chapters go deeper from here

• The Service Control Manager — the actual orchestrator: how it reads configuration, resolves dependencies, and answers control requests like start/stop/pause.
• Service hosts — why dozens of unrelated-looking services often show up as one svchost.exe process in Task Manager, and what that grouping actually means.

A worked example: why "restart the service" sometimes cascades

Open Services.msc on almost any Windows machine and you'll see dependency chains: stopping one service can be blocked, or can cascade into stopping several others, because the SCM won't start a service whose declared dependencies aren't running, and (depending on configuration) may stop dependents when you stop something they rely on. This isn't a UI inconvenience — it reflects a genuine ordering constraint the SCM enforces at boot and at runtime: a service that needs the TCP/IP stack has no meaningful way to run before it, so the SCM simply won't try.

A common mistake

Killing a service's process in Task Manager is not the same as stopping the service cleanly. Especially once you understand service hosts, it should be clear why: one svchost.exe process frequently hosts several unrelated services at once, so terminating the process can take all of them down together, bypass each service's own shutdown/cleanup code, and leave the SCM believing services are still running when they aren't.

Where this connects

• Services are started as part of the same boot sequence covered in Startup & shutdown, specifically after the kernel and Executive are already initialized.
• Every service runs under a security context defined by access tokens — usually one of the built-in service accounts rather than a human user's.
• ALPC & local RPC is how most services actually communicate with the SCM and with each other, rather than sharing memory directly.