Plug and Play & power

Drivers & device stacks assumed a device stack already exists. This chapter is about the two coordinated systems that bring one into existence in the first place, and that then keep the resulting hardware in the right power state as conditions change: Plug and Play (PnP) and power management.

PnP answers "what devices exist right now"

Modern Windows doesn't require hardware to be manually declared to the OS ahead of time. When a bus driver (Drivers & device stacks) enumerates its bus and finds a device that wasn't there before — a USB drive plugged in, a new PCIe card detected at boot — it reports this to the PnP Manager, which then:

1. Identifies the device (via hardware IDs the device itself reports).
2. Locates and loads the appropriate driver(s) — function driver, any relevant filter drivers — for that specific hardware.
3. Builds out the device stack described in the previous chapter, dynamically, for this newly-discovered device.
4. Notifies interested components (user-mode applications that registered for device-arrival notifications, for instance) that a new device is now available.

Removal works symmetrically: the PnP Manager coordinates an orderly teardown of the device stack when hardware is unplugged or disabled, giving drivers a chance to clean up rather than simply vanishing out from under in-flight I/O.

Power management answers "what state should each device be in, right now"

Separately, but cooperating closely with PnP, the power manager coordinates transitions between power states — for individual devices (via D-states, roughly "how active is this specific device right now") and for the system as a whole (sleep, hibernate, full shutdown). This isn't purely a hardware concern the OS can ignore: drivers have to actively participate, saving whatever state is needed to resume correctly and acknowledging power-state change requests, because the OS genuinely cannot power down or suspend a device safely without the driver's cooperation.

Why these two systems have to cooperate, not just coexist

PnP and power management are conceptually separate questions — "what exists" versus "what state is it in" — but they interact constantly in practice: a device can't be power-managed if the PnP Manager hasn't finished bringing its stack online yet, and a device being removed while suspended needs both systems to agree on the correct sequencing. This is exactly the kind of cross-cutting coordination problem that justifies dedicated infrastructure rather than leaving it to individual drivers to improvise correctly and consistently — mistakes here have historically been a real source of Windows' reputation (now largely resolved) for unreliable sleep/resume behavior.

A worked example: closing a laptop lid

Closing a laptop's lid triggers a coordinated sequence involving both systems at once: the power manager begins transitioning the system toward a sleep state, individual drivers are asked to save whatever state they'll need to resume correctly and move their devices to a low-power D-state, and — critically — this has to happen in a specific, dependency-aware order (a storage driver needs to finish or safely pause any in-flight I/O before the underlying device is powered down, for instance). None of this is "the hardware just turns off" — it's an actively negotiated transition, with drivers as willing participants, not passive victims of a sudden power cut.

A common mistake

Treating power management as purely a hardware or firmware-level concern the OS can stay uninvolved in badly misreads how deeply the OS and drivers actually participate. A driver that doesn't correctly implement power-state transitions can cause a whole class of real, user-visible problems — a laptop that won't wake correctly, a device that stops responding after resume — that have nothing to do with the underlying hardware being faulty, and everything to do with the software-level coordination this chapter describes not having happened correctly.

Where this connects

• Drivers & device stacks is what the PnP Manager actually assembles and tears down as devices arrive and depart.
• Startup & shutdown covers where boot-time device enumeration fits into the wider sequence from power-on to a usable desktop.