Skip to content
WinBookUnofficial

Modern Standby: is the laptop actually sleeping?

Verified 2 min read

How S0ix differs from S3, why a closed laptop drains battery, and how to find out what kept the machine awake.

Tested onPro (26H2) · Build 26300.9457 · x64
E1
Build
26300.9457
Edition
Pro (26H2)
Architecture
x64
Support
Documentation (E1)
Evidence
E1Official documentation
Verified
2026-10-29
Page type
Troubleshoot

The short answer

Section titled “The short answer”

Most modern laptops do not sleep in the old sense. They use Modern Standby (S0 low-power idle): the system stays in a low-power state with the OS still running, so it can wake instantly and keep network tasks alive.

The trade-off is real:

  • wake is fast (no hibernate resume);
  • background work can continue — including work you did not want;
  • a misbehaving driver or app keeps the SoC out of its deepest idle state, and the laptop drains in a bag.

S3 (the old suspend-to-RAM) is rare on new machines; the firmware decides which model is available, not Windows.

Check which model the machine uses

Section titled “Check which model the machine uses”
Terminal window
# which sleep states are available
powercfg /a
# what the platform actually supports (S0ix low-power idle)
powercfg /sleepstudy /output $env:TEMP\sleepstudy.html

powercfg /a prints something like:

  • 待机 (S0 低电量待机) — Modern Standby is active;
  • 待机 (S3) — classic suspend;
  • 休眠 — hibernate available or not.

If S3 is not listed, you cannot switch to it with a setting. Some OEM firmwares expose a “S3 sleep” option in BIOS; most new machines do not.

Verify the drain with data, not impressions

Section titled “Verify the drain with data, not impressions”
Terminal window
# battery report: capacity and recent drain
powercfg /batteryreport /output $env:TEMP\battery.html
# what woke / kept the system awake
powercfg /sleepstudy /output $env:TEMP\sleepstudy.html

The sleep study shows sessions by duration and the top offenders that prevented deep sleep: a driver, a service, or a scheduled task. Open the HTML in a browser; the tables are readable.

Typical offenders:

Culprit Tell
Network adapter (WoWLAN) network activity during standby
USB device / dock device remains powered
Indexing or backup task scheduled task ran during standby
Browser with audio/video process held a power request
Driver bug (GPU/audio) no obvious app, but active time high

Find the process holding a power request

Section titled “Find the process holding a power request”
Terminal window
# requires the appropriate privilege; shows requests preventing sleep
powercfg /requests

This is the fastest single command for “the lid is closed, why is it warm”. It lists display, system and away mode requests with the requesting process. Close that process and retest.

Reduce the drain without disabling standby

Section titled “Reduce the drain without disabling standby”
  1. Disable wake-on-LAN / WoWLAN if you do not need it.
  2. Unplug the dock when the laptop travels — docks keep devices powered.
  3. Check scheduled tasks: Get-ScheduledTask | Where-Object { $_.Settings.WakeToRun }.
  4. Update the GPU/audio drivers — these are the most common standby regressions.
  5. Hibernate after a timeout if standby drain is unacceptable; hibernate is slower to resume but loses nothing.

What “connected standby” does to battery over a day

Section titled “What “connected standby” does to battery over a day”

Rough expectations from vendor data (not a measurement here):

  • a healthy machine loses low single-digit percent overnight;
  • losing more than ~5%/hour in a bag means something is holding the system awake;
  • a machine that is warm to the touch after 30 minutes in a bag is not idle.

Use the sleep study’s per-session active/residency numbers rather than a single percentage.

Section titled “Related”

Lab boundary

Section titled “Lab boundary”

E1. S0ix/S3 behaviour is documented by Microsoft and implemented by firmware. The lab’s virtual machines have no battery and no S0ix path, so no drain was measured here.

Sources