I pulled my laptop out of my bag after a commute lasting a little over an hour, and it was warm. Not “just came off my desk” warm. Bag-cooking warm, with 18% of the battery gone from a machine that was supposedly asleep the entire time.

I had blamed Modern Standby for years, muttering that “Windows sleep is bad” whenever my laptop emerged from a bag warmer and emptier than I expected. That explanation had become so convenient that I never stopped to check whether my laptop even used Modern Standby.

When I finally asked Windows to show me what had happened, it dismantled my diagnosis almost immediately. My laptop used traditional S3 sleep, and during the matching 1 hour and 21-minute session, it had never entered that sleep state at all.

I had been blaming the wrong kind of sleep

This laptop does not even support modern standby

I started by opening Windows Terminal to check the power states my laptop supported:

powercfg /a

The command lists all available sleep states on a Windows computer, along with the reasons any unavailable states cannot be used. On my laptop, Standby (S3) and Hibernate appeared under the available states. Standby (S0 Low Power Idle) appeared further down as unavailable because the system firmware did not support it. That ruled out Modern Standby before I had even generated a report.

Windows Modern Standby uses the S0 Low Power Idle state, allowing a computer to move between low and higher activity without leaving S0. Traditional S3 sleep behaves differently. The processor and some other hardware power down, normal computational work stops, and only system memory remains powered, so Windows can restore the session when the computer wakes.

My laptop therefore had the older sleep model that I had incorrectly assumed Windows had abandoned. If it entered S3 when I closed the lid, applications should not have continued working throughout my commute. The question was no longer why the laptop consumed so much power during Modern Standby. I needed to know whether it had entered sleep in the first place.

Windows recorded the difference between a dark screen and sleep

The display went off, but the computer stayed busy

The tool I needed was already built into Windows. I opened Windows Terminal with administrator privileges and ran:

powercfg /sleepstudy /output "C:sleepstudy-report.html"

Within a few seconds, Windows saved an HTML file to the root of my C drive. Despite the command name, the document opened as a System Power Report, and its header confirmed what powercfg /a had already revealed:

MODERN STANDBY ENABLED No

Microsoft describes both /sleepstudy and /systempowerreport as commands that generate diagnostic reports about system power transitions. The resulting report can also contain useful information about computers following the traditional S3 power model. Below the header was a timeline showing how my laptop had moved between Active, Screen Off, Standby, Hibernate, and Shutdown.

Turning off a display does not necessarily mean the computer has entered S3. Windows can darken the screen while the rest of the system remains active, allowing applications and hardware to continue using power.

I matched the report’s start time to when I closed the lid at the beginning of my commute. Windows recorded the following 1 hour, 21 minutes, and 42 seconds as Screen Off rather than Standby. During that period, the laptop consumed 9,968 mWh, lost 18% of its battery, and maintained an average drain rate of 7,320 mW.

The genuine sleep sessions appeared elsewhere in the same table as separate Standby entries. Windows was not telling me that the laptop had gone to sleep inefficiently during the commute. It was showing that the machine had never entered S3 during that period. Closing the lid had switched off the display, but the system underneath had remained awake. That explained the heat inside my bag and the battery loss without requiring any theory about broken modern standby behavior.

It also explained why the report’s Low Power State Time column contained only dashes. That metric belongs to the low-power behavior of modern standby systems. My laptop did not use S0 Low Power Idle, so there was no DRIPS percentage to inspect. Microsoft’s documentation also distinguishes the Screen Off and Sleep phases used in Modern Standby reports from the traditional S3 model, where software activity stops once the machine reaches S3.

The report narrowed the problem without inventing a culprit

Windows gave me an answer, just not a neat one

I had initially expected to find one badly behaved application holding the computer awake. To check, I ran another built-in command:

powercfg /requests

This lists power requests currently being held by applications and drivers, making it one of the more useful commands for troubleshooting Windows sleep mode issues. A SYSTEM request, for example, can tell Windows to remain running rather than entering sleep after a period of inactivity. My result was less dramatic. DISPLAY, SYSTEM, AWAYMODE, and EXECUTION all returned None. The only listed item was a Legacy Kernel Caller under PERFBOOST, not an application holding the SYSTEM request I had expected to find.

That did not prove that no request had interfered with the earlier sleep transition. powercfg /requests only captures requests active at the moment the command runs, so anything that had already released its request would be absent by the time I reopened the lid and checked. Microsoft provides longer-running diagnostic tools for situations where a request needs to be recorded as it appears and disappears.

Still, the System Power Report had already changed the investigation. I was no longer hunting for an application draining the battery while the computer slept. I was looking for whatever had prevented the laptop from reaching S3.

The first place to check among Windows’ sleep settings is the lid action under Control Panel -> Hardware and Sound -> Power Options -> Choose what closing the lid does. The On battery option should be set to Sleep, rather than Do nothing. From there, the cleanest test is to note the battery level, unplug the laptop, close the lid for at least an hour, and generate another report after reopening it.

The important result is not merely lower battery drain. The matching session should appear as Standby, showing that Windows completed the transition into S3 rather than stopping at Screen Off.

The problem was not bad sleep; it was no sleep at all.

Windows did not prove that my laptop was bad at sleeping. It showed that after I closed the lid, the machine remained in Screen Off for the entire 81-minute session instead of entering S3. That was less convenient than blaming Modern Standby, but it gave me something much more useful: the right problem to solve.