Device Power States Explained: D0, D1, D2, D3hot, and D3cold

Windows and ACPI use D0, D1, D2, and D3 to describe the power state of an individual device. A GPU, network adapter, storage controller, USB device, or another component can therefore have a device power state that is distinct from the power state of the computer as a whole.

Microsoft defines D0 as the fully on working state and D1 through D3 as low-power states. Starting with Windows 8, Windows distinguishes D3hot and D3cold as two substates of D3. The names form a useful hierarchy, but they are not universal operating modes that every piece of PC hardware implements in exactly the same way.

D0 is the straightforward state: the device is powered for normal operation, active, and responsive. ACPI describes D0 as the fully-on state in which the device receives full power needed for operation and delivers its functionality. Windows similarly treats D0 as the device working state.

That does not mean every circuit inside a modern device must consume its maximum possible power whenever the device is in D0. Hardware can have internal clock gating, link power management, frequency scaling, or other mechanisms below this abstraction. D0 says the device is operational from the operating system power-policy perspective; it is not a wattage reading.

D1 and D2 are intermediate low-power states, but treating them as mandatory rungs on a ladder is a mistake. Microsoft explicitly notes that many device classes do not define these states. ACPI likewise leaves D1 and D2 undefined for its default device class and supplies class-specific definitions where they make sense.

In the general ACPI model, D1 is shallower: it is expected to save less power and preserve more device context than D2. D2 can permit greater power savings at the cost of losing more context and taking longer to restore. The precise meaning, wake capability, timing, and retained functionality still depend on the device class, bus, platform, and driver.

D3 is the deepest device low-power state, but D3hot and D3cold matter because “off” can describe two materially different hardware situations. In D3hot, the device is mostly powered down while remaining connected to its main power source sufficiently for the parent bus to detect it. ACPI requires D3hot devices to remain enumerable by software.

Windows describes D3hot as the D3 substate that a device can enter directly from D0 under software control. The device may have lost operational context and may require driver restoration or reinitialization before it can work again. Bus visibility therefore does not imply that the functional blocks of the device are still running.

D3cold goes deeper. Microsoft describes it as a state in which the device is physically connected but cannot be detected by the bus until it is powered again. Its main power source can be removed. ACPI likewise describes the off/D3cold condition as losing device context and software enumerability, with operating-system software reinitializing the device after power returns.

This distinction is why D3cold support is a platform property as well as a device property. Microsoft states that the device, parent bus driver, and platform firmware must all support the transition. Shared power resources can matter too: one device that cannot enter D3cold may prevent a shared bus or power resource from reaching a deeper state.

Windows allows a device to enter D3cold only from D3hot. A driver can indicate that its device is prepared for D3cold, but Microsoft documents that the subsequent D3hot-to-D3cold transition can depend on the parent bus, ACPI, shared power resources, and platform conditions rather than another direct command from the function driver.

Returning from D3cold goes to D0, not back to D3hot as an intermediate software-visible working step. Power restoration can also affect other devices sharing the same source, which is one reason drivers and the platform need an explicit power-management contract rather than applications forcing these states themselves.

The useful mental model is a trade-off, not a performance ranking. Deeper low-power states can save more energy, but the device may retain less context and require more work before it becomes usable again. Wake capability can also constrain the deepest state that is practical for a particular device and system scenario.

Microsoft gives this reasoning explicitly for devices that use D1 or D2: a shallower state can reduce perceived resume delay, while a deeper state can prioritize power conservation. In D3cold, the cost can extend to restoring power and fully reinitializing hardware. Exact transition times are device-specific, so a D-state name alone cannot predict a user-visible delay.

System power states describe the computer as a whole, while D-states describe devices. The two layers interact: Windows power policy maps system states and wake requirements to appropriate device states, and many devices enter deeper states when the system sleeps. But the mapping is not simply “S0 means D0” and “sleep means D3.”

Modern Windows can place supported idle devices into D3cold while the computer remains in the S0 working system state. Conversely, a device needed for wake or another platform function can need a shallower state while the system is entering a low-power condition. This is why system state and device state should be discussed separately.

CPU C-states describe processor idle behavior. They are another power-management abstraction with their own rules, latency trade-offs, and hardware implementation. A processor core entering a C-state does not mean a PCIe device has entered the same-numbered D-state, and a device entering D3 does not imply that the CPU has entered a particular C-state.

A real PC can coordinate CPU idle states, device D-states, PCIe link power management, platform power rails, and system sleep policy at the same time. Similar numbering across some of these mechanisms should not be read as a shared state machine.

The fact that D3cold can reduce idle power does not make “force every device into D3cold” a valid PC tuning rule. Whether a state is available depends on hardware, firmware, bus support, driver policy, wake requirements, and shared platform resources. Some device classes do not even define D1 or D2.

For normal systems, supported Windows drivers and platform firmware should negotiate these states through their documented power-management paths. If a specific device has a resume, wake, battery, or idle-power problem, diagnose that device and its supported settings. Disabling wake features or changing driver-owned power policy blindly can trade one problem for lost functionality or unreliable resume behavior.