The laptop was flat by morning: Modern Standby, the sleep state your fleet actually uses

The ticket always reads the same way. "I closed the lid at 6pm with 80 percent. At 8am it was flat." Somebody checks the power plan, sees Sleep set to 15 minutes, declares the settings correct, and closes the ticket as user error. Then it happens again on a different model, and again on a whole batch of a new hardware refresh. The reason this keeps happening is that almost nobody in the helpdesk chain knows that the laptop never went to sleep in the way they are imagining. On most modern hardware, "sleep" is not the old S3 state where the CPU is parked and RAM is merely refreshed. It is a state where Windows is technically still running, drivers are still loaded, the network can still be alive, and any badly behaved component can quietly burn a battery all night behind a closed lid. This post explains what that state actually is, how to tell which one a device is in, and which built-in reports name the exact component that drained the battery.

The problem: the lid was shut and the battery still went

Two different tickets share one wrong diagnosis. Learn to tell them apart before you touch anything.

The first shape is overnight drain. The lid is closed, nobody touches the machine, and the battery loses far more charge than it should. The user reports "it does not sleep properly". They are closer to right than the helpdesk usually admits.

The second shape is the machine wakes up on its own. The user finds the fan spinning in a bag, or the machine warm, or the lock screen already on when they open the lid. Sometimes both shapes happen on the same device, because a wake is what starts the drain.

The wrong diagnosis in both cases is "the power plan is misconfigured". The power plan usually is not misconfigured. What is actually happening is that the sleep state itself behaves nothing like the one the engineer is picturing.

Here is the sentence to internalise. Microsoft's own documentation of ACPI system power states says of the Modern Standby state: "the system remains partially running". Not off. Not parked. Partially running. Everything else in this post follows from that.

Read the second and third rows together. S1-S3 is the state where the machine "appears to be off" and only memory refresh keeps state alive. S0 low-power idle is a variant of the working state. That is not a naming quirk. It is the mechanism, and it is why an app can keep a Modern Standby laptop busy all night in a way it never could on an S3 machine.

Why it happens: S0 low-power idle is the working state with the screen off

What Modern Standby actually is

Modern Standby is Microsoft's name for the S0 low-power idle power model on Windows PCs. The documentation describes it as an expansion of the Windows 8.1 Connected Standby model, extended to hardware that could not meet the original Connected Standby bar, including systems with rotational or hybrid storage and network adapters that lack the full offload capability.

The design goal is a phone-like experience: "instant on / instant off", with the network stack able to stay alive so the device can be woken by a packet as well as by a button. The documentation is explicit that Windows and the SoC "are always listening for interesting events (such as a network packet or user input at a keyboard) and will wake up instantly when needed".

Two consequences fall out of that design, and they are the entire root cause of the drain tickets:

1. Because the system is still running, software can still run. Microsoft calls the components allowed to keep the SoC active activators, because they register with the power manager as capable of blocking the return to the idle power mode.
2. Because the network can stay alive, network events can wake the machine. That is a feature when a VoIP call arrives and a defect when a driver wakes the machine every four minutes.

Screen Off is not Sleep

Microsoft splits a Modern Standby session into two documented states, and you need both names to read the reports later.

DRIPS is worth spelling out because every report uses it: deepest runtime idle platform state. It is the state in which, per the documentation, "no software activity runs whatsoever". A sleep session with a low DRIPS percentage is a session where something kept waking the silicon up.

The phase chain: where a blocker actually blocks

When the screen turns off, Windows walks a documented, sequential set of phases to quiet the system down. Each phase must complete before the next starts. This is the chain to picture when a machine "will not go to sleep".

Notice the first row. On AC power, one application holding a power request blocks sleep entry indefinitely. On battery it blocks for up to five minutes. That five-minute figure is documented twice: in the phase table and in the power request reference, which states "on Modern Standby systems on DC power, power requests are terminated after 5 minutes". Microsoft also tells you exactly how to find the culprit: "The applications with power requests can be inspected by running Powercfg.exe with the /requests option."

The two variants: connected and disconnected standby

Modern Standby comes in two flavours, and the difference is entirely about whether the network survives the sleep.

• Connected Standby. The network adapter supports the required protocol offload and wake-pattern behaviour, so the system can stay on the network during standby.
• Disconnected Standby. Microsoft's definition is precise: "If a system's NIC is not offload-capable, but the system reports in the FADT table that it supports S0 low power idle, it is using Disconnected Standby." FADT is the ACPI Fixed ACPI Description Table, one of the firmware tables that advertises platform capability.

You do not guess which one you have. The distinction shows up as literal text in the powercfg /a output, and that command is covered in the next section.

There is a third behaviour layered on top since Windows 10 version 2004: Adaptive Connected Standby (ACS), which is now the connectivity default on Modern Standby systems. With ACS, Windows itself decides whether to keep connectivity alive while on battery. It grants Internet connectivity to apps that need it, such as when Remote Desktop is enabled or a UWP app is set to always run in the background, and otherwise quiesces networking during sleep while keeping the network instantly ready on resume. The documentation notes that ACS decides the connectivity type at the start of a sleep session and keeps it for the whole session.

The 24H2 change you will trip over

Windows 11 version 24H2 added a defensive behaviour that changes what you will observe on newer builds. The wake sources documentation states that "a new power-saving measure was introduced to Modern Standby to prevent unexpected battery drain. If excessive battery drain is detected, most wake sources will be disabled. In this state, the device can be woken from Modern Standby by pressing the power button or opening the lid."

That has a direct diagnostic consequence. A user reporting "my machine will not wake on a key press any more" on 24H2 may be seeing Windows protecting itself from a drain problem you have not found yet. The sleepstudy exit-reason list includes matching codes for it, documented as Restricted Standby Battery Drain Budget Exceeded, Restricted Standby Doze Timeout and Smart Restricted Standby. Two other 24H2 behaviour changes belong in the same mental note: pressing the power button now engages input suppression so the display will not turn on in clamshell mode with the lid closed unless an external display is attached, and Voice Input is no longer supported as a wake source from sleep.

The binaries and the database behind all of this

Naming the components makes the flow concrete. Everything below was confirmed present on a Windows 11 Enterprise build 26200 device; the role descriptions come from Microsoft documentation where documentation exists, and I flag where it does not.

Services and the one scheduled task

Four services and one task are worth knowing by name on a drain investigation.

That task existed and was in the Ready state on the test device. It is the in-box power efficiency analysis task. It is the only scheduled task under \Microsoft\Windows\ that is dedicated to power efficiency diagnostics, so if you are looking for "the built-in thing that checks power health", that is it.

How to verify: powercfg first, reports second, guessing never

Step one, always: which sleep model is this

Every investigation starts with one command. powercfg /a reports the sleep states available on the system and, per the documentation, "attempts to report reasons why sleep states are unavailable". Run it from an elevated prompt.

Now read the reason strings, because they are the part everyone misinterprets.

Step two: what is holding the system awake, and what is armed to wake it

These four commands answer the two questions that actually matter. Run them elevated; without administrator rights the request and timer output is incomplete, which is worse than no answer because it looks clean.

The request categories in that output deserve a table, because the names in the tool and the names in the API do not line up perfectly and that trips people up.

Step three: the reports that name the offender

The live commands tell you about now. The reports tell you about last night. There are five, all built into powercfg.exe, and each writes a file into the current directory unless you pass /output.

How to read a sleepstudy summary table without a manual: the rows are colour-coded, and the thresholds are documented. For a Sleep session, red means the DRIPS rate is under 80 percent or the drain rate is at or above 1 percent per hour. Yellow means DRIPS between 80 and 94 percent, or drain between 0.33 and 1 percent per hour. Green is everything else. Sessions under two minutes show no detailed data. Overall sessions shorter than ten minutes are not tracked at all, so a five-minute lid-close test tells you nothing.

Step four: the event log

Two providers matter, both writing to the plain System log. There is no dedicated operational channel for power on Windows client.

Microsoft does not publish a consolidated Event ID reference page for Microsoft-Windows-Kernel-Power on Windows client. So rather than invent meanings, the message strings below were read directly from the provider's own manifest on a Windows 11 build 26200 device using wevtutil gp Microsoft-Windows-Kernel-Power /ge:true /gm:true, and cross-checked against real records in the System log on that device. That is the authoritative source for the string; it is not a documented contract, so do not treat the IDs as a stable API.

The second provider is the useful one for a single question: what woke it.

The fix: policy the wake surface, not the sleep state

You cannot change the sleep model. So everything you can actually do falls into three buckets: stop things holding power requests, stop things arming wake timers, and set the timeouts sensibly. All three are configurable, and all three have both a Group Policy and an Intune path.

The registry surface, and an honest caveat about it

Most power configuration is not registry-first. Power schemes, subgroups and settings are addressed by GUID through powercfg and the power API, and Microsoft's own guidance for reading and writing them is powercfg /query, /setacvalueindex and /setdcvalueindex, not registry editing. There is no documented registry key that holds "the current sleep timeout" for you to read.

What is documented is the policy side. Every ADMX-backed power policy states its registry key and value name, so the following table is a genuine documented reference rather than a reverse-engineered one. All of these hang off one parent key.

Two more documented registry facts sit outside that parent key and are worth knowing.

Group Policy: the exact click path

Every setting in the table above lives in Power.admx, under one branch. Here is the full path and the walkthrough.

1. Open the Group Policy Management Editor on your policy, or gpedit.msc for a local test.
2. Navigate to Computer Configuration > Administrative Templates > System > Power Management > Sleep Settings.
3. Open Allow applications to prevent automatic sleep (on battery). Read the help text carefully before choosing. Enabling this policy means "any application, service, or device driver prevents Windows from automatically transitioning to sleep". Disabling it is the restrictive choice: only user input then determines whether Windows sleeps. Set it to Disabled if you want to neutralise misbehaving power requests, and set the plugged-in twin the same way.
4. Open Specify the system sleep timeout (on battery) and set a value in seconds. Do the same for the plugged-in variant.
5. Open Specify the unattended sleep timeout (on battery). This is the one that governs sleep when nobody is at the machine. Remember that 0 seconds means Windows will never automatically sleep.
6. If you need connectivity behaviour pinned rather than left to Adaptive Connected Standby, open Allow network connectivity during connected-standby (on battery) and (plugged in). Enabled maintains connectivity in standby. Disabled means connectivity "isn't guaranteed", and the documentation adds that the restriction "currently applies to WLAN networks only, and is subject to change".
7. For the lid and buttons, move up one level to Power Management > Button Settings and set Select the lid switch action and Select the Power button action.
8. Close the editor and run gpupdate /target:computer /force on a test device, then re-run powercfg /q SCHEME_CURRENT SUB_SLEEP and confirm the indexes changed.

Intune: the settings catalog path

There is no separate Intune template for power. These settings come through the settings catalog, generated from the Policy CSP, so you build a settings catalog profile and pick them out of the picker.

1. Sign in to the Microsoft Intune admin center with an account holding at least the Policy and Profile Manager built-in role.
2. Select Devices > Manage devices > Configuration > Create > New policy.
3. Set Platform to Windows 10 and later and Profile type to Settings catalog. Select Create.
4. Name it something a future you will recognise, such as Win11: Modern Standby power baseline. Select Next.
5. On Configuration settings, select Add settings, then type sleep in the search box. The picker returns the Power category for the Policy CSP settings and the Administrative Templates categories for the ADMX-backed ones.
6. From the Power category, add Standby Timeout On Battery, Standby Timeout Plugged In, Unattended Sleep Timeout On Battery and Select Lid Close Action On Battery. The tooltips link straight to the CSP page for each one.
7. Search again for connected-standby and add Allow network connectivity during connected-standby for both power sources if you are pinning that behaviour, and prevent automatic sleep for the power-request lever.
8. Set each value. Close the picker, select Next, add scope tags if you use them, then assign to a small pilot group first.
9. On Review + create, select Create. After the next device check-in, verify on a target device with powercfg /q SCHEME_CURRENT SUB_SLEEP and by reading the policy registry key from the table above.

If you need the raw OMA-URIs for a custom profile or another MDM, these are the documented ones.

Defender and security policy: mostly N/A, with one real exception

There is no Defender profile, no attack surface reduction rule, no exploit protection mitigation and no WDAC or firewall setting that governs Modern Standby. If you were expecting an Endpoint Security profile in this post, there genuinely is not one, and saying so is more useful than inventing a link.

The one real intersection is virtualization-based security. Look again at the powercfg /a output earlier in this post: against Standby (S3) the device reported "The current Device Guard configuration has disabled this standby state", and against Hybrid Sleep it reported "The hypervisor does not support this standby state". On a device with VBS or Credential Guard enabled, your security baseline is one of the things removing legacy sleep states from the menu. That is worth knowing before someone spends a week trying to "re-enable S3" on a hardened fleet.

Proof it worked: a real run on a Modern Standby laptop

The companion script for this post pulls the whole first pass into one read-only report: supported sleep states and the standby variant, the active scheme and its sleep subgroup indexes, current power requests, armed wake timers and wake-armed devices, battery full-charge versus design capacity, the policy registry key, and a count of the sleep and wake events. It changes nothing. It does not even generate a report file, precisely so it can be run against a user's machine during a call without leaving anything behind.

Here is a genuine run on the Windows 11 Enterprise build 26200 test laptop, with the computer name and one scheduled task name replaced. Output is abridged to the sections that carry the verdict.

Read that exit code as the feature it is. Exit 0 means every read succeeded. Exit 2 means the report printed but at least one field is genuinely unknown, so you should not tick the box. Exit 1 means a critical read failed, or the session was not elevated, and the script aborted rather than tell you that nothing is holding the machine awake when it simply could not look.

Closing the loop with the built-in reports

Once the script has told you the sleep model and pointed at a suspect, run the two reports it deliberately does not generate. Do it in a directory you chose, from an elevated prompt, because both write files.

The order matters. Sleep model, then live requests and timers, then the per-session report, then per-app energy. Every step narrows the suspect list from a whole machine to one component with a name you can act on. That is the whole difference between "the laptop drains overnight" and "the nightly inventory task arms a wake timer at 02:09 and the machine never gets back to DRIPS afterwards".

References

Microsoft-official sources for everything asserted above.

• Modern Standby - the definition, the relationship to Connected Standby, and the statement that the power model cannot be switched without an OS reinstall.
• System power states - the ACPI state table, the S0 low-power idle row, and the caution against legacy S3 Wake-on-LAN on Modern Standby systems.
• Overview of Modern Standby Validation - how to use powercfg /a to identify Modern Standby, and the exact Network Connected versus Network Disconnected output.
• Powercfg command-line options - every option, argument and output file referenced in this post.
• Modern standby SleepStudy - report contents, colour-coding thresholds, offender types and the exit-reason table.
• Prepare software for modern standby - the phase chain and the five-minute DC power-request block.
• Modern Standby states - Screen Off versus Sleep, and DRIPS.
• Modern Standby Wake Sources - the wake source tables and the Windows 11 24H2 excessive-drain behaviour.
• Network connectivity - Adaptive Connected Standby and the "Networking in standby" field in the system power report.
• POWER_REQUEST_TYPE - the four documented power request types and their effects.
• Power Policy CSP and ADMX_Power Policy CSP - OMA-URIs, ADMX mappings, GPO paths and registry key names.
• Create a policy using settings catalog in Microsoft Intune - the admin center navigation used above.

Community deep-dives, both fetched and confirmed on topic before citing.