IPC & component boundaries

System support processes & services introduced a Windows machine as dozens of separate processes — Winlogon, the SCM, individual services, user applications — each isolated in its own address space by the same protection System architecture described. Isolation is good for stability and security, but it creates an obvious problem: those processes still need to cooperate. A service has to answer a management tool's request. A GUI app has to ask a privileged service to do something the app itself isn't allowed to do. Inter-process communication (IPC) is the umbrella term for how Windows solves that problem without giving up isolation.

Why not just share memory?

The direct answer — let process A read and write process B's memory — is exactly what process isolation exists to prevent, and for good reason: it would mean any bug or compromise in one component could corrupt or spy on any other, defeating the entire point of separating them into processes in the first place. So Windows requires cooperation to go through mediated channels: named, discoverable endpoints that enforce structure (you can't send arbitrary bytes into arbitrary places) and security (a security descriptor still gates who can even connect) at the same time.

This chapter is the overview; the next three go one layer deeper into specific mechanisms, roughly ordered from the one you'll recognize most easily to the one running underneath the other two:

• Named pipes — a durable, named rendezvous point for client/server communication, conceptually the simplest of the three.
• RPC & COM foundations — lets a client call what looks like an ordinary function, while the actual work happens in another process (or another machine) entirely.
• ALPC & local RPC — the fast, same-machine transport that a great deal of "local RPC" traffic actually rides on underneath.

IPC is a security boundary as much as a messaging system

Every IPC mechanism in Windows carries the same access-control machinery as a file or registry key: named pipes have security descriptors (Security descriptors & ACLs covers exactly how those are structured), RPC endpoints can require specific authentication levels, and ALPC ports check the caller's token before accepting a connection. This matters practically: a service exposing an IPC endpoint isn't just choosing a transport, it's choosing exactly who is allowed to ask it to do things — which is precisely the kind of decision that, done carelessly, turns a background service into a privilege-escalation path.

A worked example: clicking a button in a management console

When an administrative tool's UI shows a button like "restart this service" or "change this setting," the click essentially never does the privileged work itself. Instead, it typically:

1. Calls into an RPC client stub for whatever management interface the target component exposes.
2. That stub marshals the request and hands it to the RPC runtime, which — for a same-machine target — very likely picks a transport that rides on ALPC.
3. On the other side, a privileged service (often reached indirectly through the SCM) unmarshals the request, checks the caller's token against its own policy, and performs the actual privileged operation.

The UI process itself may never have the rights to make that change directly — it doesn't need them, because it isn't doing the work itself, only asking a more privileged component to do it on its behalf.

A common mistake

IPC is easy to write off as a niche, advanced-only subsystem irrelevant to daily use. In practice it's closer to a load-bearing default: named pipes, RPC, and ALPC are how an enormous share of ordinary Windows functionality — service management, security policy queries, print spooling, much of COM — actually works, running constantly and invisibly under features that look, from the outside, like they're happening inside a single process.

Where this connects

• Access tokens is what every IPC endpoint's access check is actually evaluating.
• The Service Control Manager and most services rely on IPC as their primary way of being controlled and queried from the outside.