Why a Dell XPS wakes in your backpack, cooks itself, and arrives with a dead battery, and how to diagnose it with powercfg instead of guessing.
You close the lid, slide it into a bag, and arrive to a hot chassis, a fan you can hear through the fabric, and a battery that has quietly emptied itself. The machine was never asleep. On Modern Standby, closed and asleep are unrelated states, and on a lot of XPS units the setting that connects them is switched off and hidden from the interface at the same time.
Here is what a week of that looks like, measured on a Dell XPS 17 9710 running Windows 11 25H2:
STANDBY TIME 0.6% 61.3 minutes across a full 7-day week
STANDBY DRAIN 549 mW measured over 119 hours with the lid shut
HELD BY ONE APP 97.8% of every standby session, by a single utilityA healthy machine of this class idles at roughly 50 to 100 mW.
Everything below can be run by hand. If you would rather not, I packaged the whole diagnostic pass into a single read-only PowerShell script that prints the offenders ranked: Find-PowerBleed.ps1.
The symptom
It shows up in three shapes, and they are the same fault wearing different clothes.
The backpack. You shut the lid between meetings. Forty minutes later the underside is too warm to rest on your legs, the fans are audible, and you have lost a third of the battery. In a padded compartment there is nowhere for that heat to go, so the machine throttles, spins the fans harder, and drains faster.
The overnight. You close it at 80%. In the morning it is at 4%, or it has turned itself off entirely and lost your open windows. The event log records an unclean shutdown, which looks alarming and is usually nothing of the sort.
The plugged-in one. The machine is on the charger, so the battery never moves, and it simply never sleeps at all. Weeks pass. The only clue is that it runs warm and the fan never fully stops.
Why sleep stopped meaning sleep
Older laptops used S3 suspend-to-RAM. The CPU stopped. Memory held its contents on a trickle of power. The machine was, in every meaningful sense, off, and it stayed that way until you pressed something.
Most modern laptops, nearly every XPS since the 9500 generation, ship with Modern Standby instead, also called S0ix or S0 Low Power Idle. The firmware often removes S3 entirely, so there is no falling back to it. Check yours:
powercfg /aThe following sleep states are available on this system:
Standby (S0 Low Power Idle) Network ConnectedThe following sleep states are not available on this system:
Standby (S3)
The system firmware does not support this standby state.
This standby state is disabled when S0 low power idle is supported.
Read that first line carefully, because it is the whole problem in six words: Low Power Idle, Network Connected. The machine does not stop. It idles, keeps the Wi-Fi associated, and hands background tasks short slices of runtime so that mail arrives and updates install while the lid is down.
When that works, it is genuinely good. The SoC spends its time in a deep hardware idle state called DRIPS, Deepest Runtime Idle Platform State, and draws almost nothing. When one component refuses to go quiet, there is no floor underneath you. The machine runs at desktop power draw with the lid shut and no fan curve headroom, and nothing in the interface tells you it is happening.
S3 sleep either happened or it did not, and you could hear the difference. Modern Standby fails partially and silently. The lid closes, the screen goes off, the machine looks asleep, and underneath, it is not.
Why a bag makes it dangerous
An XPS pulls its intake air from underneath and vents through the hinge. Lay it in a padded sleeve and you have blocked both. A machine that is genuinely idling does not care: it is producing a couple of watts and the chassis absorbs it.
A machine that is awake in that sleeve is in a loop it cannot exit. Heat accumulates because there is nowhere to send it. The fans respond by spinning up, which is the noise you hear through the fabric. Higher temperatures raise leakage current, so the same work costs more power. The battery empties faster, and the aluminium acts as a hotplate against whatever is next to it.
This is why the problem feels so much worse than “my battery life is mediocre.” A 500 mW drain on a desk is a rounding error you would never notice. The same 500 mW sealed in a bag for four hours is what produces the hot, loud, empty laptop you pull out at the other end.
Four ways it fails
These are independent. You can have any combination, and fixing one while another is active produces a machine that looks fixed and is not, which is the single most common way people conclude that nothing works and give up.
Mode A: the lid genuinely does nothing
The lid-close action is set to Do nothing, and the idle sleep timeout is set to Never. Together there is no path into sleep at all while plugged in. Worse, on many OEM images the lid setting is flagged hidden, so it does not appear in Settings or Control Panel and cannot be fixed by clicking.
How you will know: zero Kernel-Power 506 events, and powercfg /q SCHEME_CURRENT SUB_BUTTONS does not list the lid at all.
Mode B: something holds a power request
Any process can call SetThreadExecutionState and pin the system awake. Media players do it legitimately during playback and release it after. Utilities like PowerToys Awake hold it deliberately and indefinitely. A held request defeats the idle timeout completely and silently.
How you will know: powercfg /requests lists anything under SYSTEM.
Mode C: something holds a standby activator
The machine does enter standby, but an app keeps the software stack busy the whole time through the Broker Infrastructure. The hardware still reaches its idle states, so superficial checks look fine, while real drain runs five to ten times over budget. Vendor bloatware is the usual offender.
How you will know: only powercfg /sleepstudy exposes this. Nothing else will.
Mode D: no floor under the battery
Hibernation is disabled by a cleanup script, a debloat guide, or a disk-space purge. But the critical-battery action is still set to Hibernate. At 2% Windows tries to hibernate, finds it unavailable, and has no fallback. The battery runs to hardware cutoff and the machine dies mid-write.
How you will know: powercfg /a says hibernate has not been enabled, and you have Kernel-Power 41 events.
Order matters. Mode B outranks the timeout fix. If you set a 15-minute idle sleep while something holds a system request, the timer never fires and you will conclude the setting did not take. It did. It just cannot win. Clear the request first, then test.
Note the asymmetry: a held power request blocks the idle timer, but it does not block an explicit lid-close or power-button action. That is why a machine can sleep reliably on the lid and never once sleep on its own.
Diagnosing it properly
Run these in order. Each one rules something in or out, and later steps are hard to interpret without the earlier ones. Open Terminal or PowerShell as Administrator. Four of the six refuse to run otherwise, and they are the four that matter.
All six steps, plus the sleep study parsing in the next section, are automated in Find-PowerBleed.ps1. It only reads, it changes nothing, and it calls powercfg by absolute path so it still works on a machine whose PATH is broken.
# from an Administrator terminal
.\Find-PowerBleed.ps1
.\Find-PowerBleed.ps1 -Days 14 -KeepReport1. Establish what sleep states exist
powercfg /aConfirms whether you are on Modern Standby, and whether hibernate is available as a fallback. If hibernate is listed as unavailable, you already have Mode D.
2. Find anything pinning the machine awake
powercfg /requestsDISPLAY:
None.SYSTEM:
[PROCESS] \Device\HarddiskVolume3\Users\you\AppData\Local\PowerToys\PowerToys.Awake.exeAWAYMODE:
None.
The fastest high-value check in the whole sequence. Everything should read None. Common finds: PowerToys Awake, Teams and Zoom during a call, browsers playing audio in a background tab, backup and sync clients mid-run, and game launchers. If the entry is a media app, close it and re-run before concluding anything.
3. List armed wake timers
powercfg /waketimersTimer set by [SERVICE] \Windows\System32\svchost.exe (SystemEventsBroker)
expires at 2:14:30 PM on 8/16/2026.
Reason: Windows will execute 'NT TASK\Microsoft\Windows\UpdateOrchestrator\
Schedule Wake To Work' scheduled task that requested waking the computer.Timers armed through SystemEventsBroker will not show up if you go looking for scheduled tasks with the “Wake the computer to run this task” flag set. Checking Task Scheduler and finding nothing does not mean there are no wake timers.
4. Generate a sleep study
powercfg /sleepstudy /output "$env:USERPROFILE\Desktop\sleepstudy.html" /duration 7The most valuable artifact by a wide margin, and the only tool that exposes Mode C.
5. Run the energy report
powercfg /energy /output "$env:USERPROFILE\Desktop\energy.html" /duration 60Traces the system for 60 seconds and audits power policy, drivers, USB selective suspend and timer resolution. It independently corroborates step 2 and catches policy problems a sleep study will not mention.
6. Read the power event log
Get-WinEvent -FilterHashtable @{
LogName = 'System'
ProviderName = 'Microsoft-Windows-Kernel-Power'
StartTime = (Get-Date).AddDays(-14)
} | Group-Object Id | Sort-Object Count -Descending |
Format-Table Count, Name -AutoSizeKernel-Power event IDs worth recognising:
506 Entering Modern Standby Carries an entry reason: Lid, Idle Timeout, Power Button
507 Exiting Modern Standby The most useful event. Holds DRIPS residency and exit reason
105 Power source changed Charger plugged or unplugged. Often the real cause of a wake
42 Entering sleep S3-era. On Modern Standby you will have none, and that is normal
41 Rebooted uncleanly Looks like a crash. Usually is not. See belowA tool that will mislead you:
powercfg /lastwakereports "Wake History Count - 0" on Modern Standby machines no matter what has been happening. It reads an S3-era structure that S0ix never populates. It is not evidence that nothing woke your machine. Use event 507 instead.
Reading a sleep study
Open the HTML in a browser. Three things matter, in this order.
How much standby did you actually get?
Before judging quality, check quantity. Add up the standby sessions across the report window. On the machine these notes come from the answer was 61 minutes across seven days, six-tenths of one percent. No amount of per-session tuning matters when the machine is barely entering standby at all. That is Mode A, and it is a configuration problem, not an efficiency one.
DRIPS residency: the hardware report card
The percentage of each session the silicon spent in its deepest idle state. Above 90% is good, above 95% is excellent, below about 70% means something is holding hardware awake.
Get Abdalla Elzedy’s stories in your inbox
Join Medium for free to get updates from this writer.
Here is the trap: DRIPS can look excellent on a machine that is destroying its own battery. The measured example held 97.4% DRIPS while drawing 549 mW, because the hardware kept dropping into idle correctly between constant software interruptions. Good DRIPS is necessary, not sufficient. Never stop here.
Activators: the software report card
This is where Mode C hides, and it is the section people skip. Aggregated across 21 standby sessions in one week:
ACTIVATOR ACTIVE SHARE VERDICT
BI -> DellMobileConnectPlus 3,593 s 97.8% CULPRIT
TCPIP-RS 57 s 1.5% normal
BI -> DellCustomerConnect 25 s 0.7% noise
BI -> DellDigitalDelivery 11 s 0.3% noise
WNS, NCSI 17 s 0.4% normalBI is Broker Infrastructure, the mechanism that grants background apps runtime during standby. One discontinued phone-mirroring utility was holding it for 97.8% of every session, in every session traced. That single line explains the 549 mW, the heat, and the flat battery.
Look for anything above a few percent that is not a networking primitive. Vendor “connect”, “update”, “assistant” and “companion” packages are the usual suspects.
This ranking is exactly what Find-PowerBleed.ps1 prints for you, walking the blocker tree down to child nodes so you get an application package name rather than just “BI”.
Drain rate
The report gives per-session battery deltas. Convert to milliwatts and compare against roughly 50 to 100 mW for a healthy 15 to 17 inch machine. Above 300 mW is broken. Above 500 mW is what cooks a laptop in a bag.
If you would rather script it: version 3 sleep study reports are template-driven. The visible HTML is scaffolding, and every number lives in a JavaScript object called LocalSprData. Extract that JSON and you can attribute standby time per application package instead of squinting at rendered tables.
The repair
Apply what your diagnosis actually found. Running all of this blind is how you end up with a machine that will not wake from its dock and no idea which change did it.
Make the lid mean something
# Lid close action -> Sleep, on both power sources
powercfg /setacvalueindex SCHEME_CURRENT SUB_BUTTONS 5ca83367-6e45-459f-a27b-476b1d01c936 1
powercfg /setdcvalueindex SCHEME_CURRENT SUB_BUTTONS 5ca83367-6e45-459f-a27b-476b1d01c936 1# Sleep after 15 minutes idle while plugged in (seconds)
powercfg /setacvalueindex SCHEME_CURRENT SUB_SLEEP STANDBYIDLE 900# Commit. Without this, nothing above takes effect.
powercfg /setactive SCHEME_CURRENT
1 is Sleep. The /setactive line is not optional, since the values sit in a pending buffer until the scheme is re-applied.
Unhide the settings the vendor removed
If the lid action never appeared in Settings, its Attributes value is 1, meaning hidden. Set it to 2 and the control returns to the normal power-options interface.
# Subgroup: Power buttons and lid
$sub = '4f971e89-eebd-4455-a8de-9e59040e7347'
$root = "HKLM:\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\$sub"# Lid close / Power button / Sleep button / Lid open
'5ca83367-6e45-459f-a27b-476b1d01c936',
'7648efa3-dd9c-4e3e-b566-50f929386280',
'96996bc0-ad50-47ec-923b-6f41874dd9eb',
'99ff10e7-23b1-4c07-a9d1-5c3206d741b4' | ForEach-Object {
Set-ItemProperty -Path "$root\$_" -Name Attributes -Value 2 -Type DWord
}Give the battery a floor
This is the step that prevents the machine dying outright. The critical-battery action is almost certainly already set to Hibernate. It just has nothing to hibernate into. Restoring hibernation also restores Fast Startup.
powercfg /hibernate on# Confirm the critical action is Hibernate (index 2)
powercfg /q SCHEME_CURRENT SUB_BATTERY 637ea02f-bbcb-4015-8e2c-a1c7b9c0b546hiberfil.sys is sized from installed RAM and can be very large, 25 GB on a 64 GB machine. If that is a problem, powercfg /h /type reduced keeps Fast Startup at a fraction of the size but gives up full hibernation. On a machine that has already killed itself once, full is the right call.
Deal with the activator
No command fixes Mode C. You remove the software, or you accept the drain.
# Confirm what you are about to remove
Get-AppxPackage -AllUsers | Where-Object Name -match 'MobileConnect' |
Select-Object Name, PackageFullName# Remove for every user, then stop it returning on new profiles
Get-AppxPackage -AllUsers -Name '<exact.package.name>' |
Remove-AppxPackage -AllUsersGet-AppxProvisionedPackage -Online |
Where-Object DisplayName -eq '<exact.package.name>' |
Remove-AppxProvisionedPackage -Online
Silence spurious wake sources
# What is currently allowed to wake the machine
powercfg /devicequery wake_armed# Disarm by exact name, quoted
powercfg /devicedisablewake "Thunderbolt(TM) Controller - 9A1F"Read before disarming. Disarming a Thunderbolt controller also stops a dock from waking the machine. No more waking by tapping a keyboard connected through the dock. If you work docked, leave these alone unless event 507 proves they are actually waking you.
Verifying
powercfg /a # Hibernate now listed as available
powercfg /requests # every category should read None.
powercfg /devicequery wake_armed # NONE, or only what you intend
powercfg /q SCHEME_CURRENT SUB_BUTTONS 5ca83367-6e45-459f-a27b-476b1d01c936
powercfg /q SCHEME_CURRENT SUB_SLEEP STANDBYIDLE# Expected: Current AC Power Setting Index: 0x00000001 (Sleep)
# Current AC Power Setting Index: 0x00000384 (900 s = 15 min)A lid setting that is still hidden will not be returned by the query at all, so the setting appearing in this output is itself the proof it is no longer hidden.
Then test for real. Close the lid, leave it alone for a few hours, and do not touch the charger. A power-source change ends a standby session and will look exactly like a spurious wake when you read the log afterwards.
Get-WinEvent -FilterHashtable @{
LogName='System'; ProviderName='Microsoft-Windows-Kernel-Power'; Id=507
} -MaxEvents 1 | ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data }SleepEntered = true
EnergyDrain = 0
DurationInUs = 1107706171 # 18 min 28 s
DripsResidencyInUs = 932415724 # 84.2% of the session
Reason = 28 # AC/DC change: the charger moved
LidOpenState = falseSleepEntered = true is the one that matters: the machine really did reach standby on lid close. Divide DripsResidencyInUs by DurationInUs for that session's residency, and check Reason before blaming the machine for waking.
Give it several days before drawing conclusions about drain. A sleep study taken minutes after removing packages and enabling hibernation will show depressed residency while Windows re-indexes and cleans up, and that is not your steady state.
Crash, or dead battery?
A Kernel-Power event 41, “the system has rebooted without cleanly shutting down first”, reliably sends people hunting for failing hardware. Most of the time, on a machine with this fault, it is the battery reaching hardware cutoff with no hibernate to fall back on. You can tell the two apart in about a minute.
Get-WinEvent -FilterHashtable @{
LogName='System'; ProviderName='Microsoft-Windows-Kernel-Power'; Id=41
} -MaxEvents 1 | ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data }BugcheckCode = 0 # no bugcheck, not a blue screen
PowerButtonTimestamp = 0 # nobody held the power button
LongPowerButtonPressDetected = false
ConnectedStandbyInProgress = true # it died inside Modern Standby
LidState = 1 # lid was closed
WHEABootErrorCount = 0 # no hardware error reported
CsEntryScenarioInstanceId = 39 # ties to a sleep study sessionBugcheckCode = 0 rules out a blue screen. Confirm it by checking that no crash dump was written at that time, and check that dumps are enabled first, because "no dump" only means something if the machine was capable of writing one.
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' |
Select-Object CrashDumpEnabled, MinidumpDir # 3 = minidump, 7 = automaticGet-ChildItem C:\Windows\Minidump | Select-Object Name, LastWriteTimeDumps enabled, older dumps present, none from the night in question: that is a positive result, not a missing clue. It says the machine could have recorded a crash and did not, because there was no crash to record.
The sleep study agrees independently. It classifies these sessions as Abnormal Shutdown, a distinct type from Bugcheck. And CsEntryScenarioInstanceId points at the exact standby session the machine died inside. Look it up and you will usually find a session that opened days earlier with the lid closed and never closed, alongside a battery trace sliding steadily to zero.
On the reference machine that trace read:
08-10 20:09 UTC 70,555 mWh (80.4%) lid closed, on battery
...119 hours at 549 mW average, 65,391 mWh consumed...
08-15 23:15 UTC 5,164 mWh ( 5.9%) last recorded sample
08-15 23:16 UTC Kernel-Power event 41
08-15 19:20 local 467 mWh ( 0.5%) boots back up on ACThe full chain: lid closed on battery, an activator holds the software stack awake, drain runs at 549 mW instead of 60, the pack empties over several days, critical-battery action is Hibernate but hibernation is disabled, no action is available, hardware cutoff, event 41. Not one component of that is a hardware fault.
What this will not fix
It does not make the machine draw zero. Modern Standby is a connected state by design. A well-behaved XPS still consumes a few percent of battery overnight. If you want genuine off, hibernate deliberately with shutdown /h before the bag.
It does not restore S3. If the firmware dropped it, there is no supported way back. Some BIOS revisions expose a toggle, most XPS units do not. Hibernation is the real substitute.
It does not undo a High Performance power scheme. That scheme pins minimum processor state to 100% on AC, disables PCIe ASPM, and runs the Wi-Fi radio at maximum performance. Those are real contributors to heat and drain, and they are deliberate choices, separate from the sleep fault, and yours to make.
It does not diagnose actual hardware. If the fans run at full speed with the lid open and idle CPU, if temperatures sit high under no load, or if the battery’s full-charge capacity has collapsed relative to design capacity, you have a different problem. Check powercfg /batteryreport and the thermals before assuming standby is at fault.
Quick reference
powercfg /a # available sleep states
powercfg /requests # what is pinning the machine awake
powercfg /waketimers # armed wake timers
powercfg /devicequery wake_armed # devices allowed to wake it
powercfg /sleepstudy /output sleepstudy.html /duration 7
powercfg /energy /output energy.html /duration 60
powercfg /batteryreport /output battery.htmlpowercfg /q SCHEME_CURRENT SUB_BUTTONS 5ca83367-6e45-459f-a27b-476b1d01c936
powercfg /q SCHEME_CURRENT SUB_SLEEP STANDBYIDLESetting GUIDs:
Buttons and lid subgroup 4f971e89-eebd-4455-a8de-9e59040e7347
Lid close action 5ca83367-6e45-459f-a27b-476b1d01c936
Power button action 7648efa3-dd9c-4e3e-b566-50f929386280
Sleep button action 96996bc0-ad50-47ec-923b-6f41874dd9eb
Lid open action 99ff10e7-23b1-4c07-a9d1-5c3206d741b4
Critical battery action 637ea02f-bbcb-4015-8e2c-a1c7b9c0b546Healthy numbers:
MEASURE HEALTHY BROKEN
DRIPS residency above 90% below 70%
Standby drain, 15 to 17 inch 50 to 100 mW above 300 mW
Top activator share below 5% above 25%
Entries under /requests 0 1 or moreWritten up from a full diagnosis of a Dell XPS 17 9710 running Windows 11 25H2 (build 26200) in August 2026. Every figure quoted (549 mW, 97.8%, 97.4% DRIPS, 61.3 minutes) is measured from that machine, not estimated.
The commands apply to any Windows 10 or 11 machine using Modern Standby. The specific offenders will differ. The method is what transfers. Registry and powercfg changes affect the whole system, so read each one before running it, and prefer applying what your own diagnosis found over applying all of it.
Script: Find-PowerBleed.ps1
Repository: github.com/AbdallaElzedy/Dell_XPS
MIT licensed. If it finds your culprit, I would be glad to hear what it was.
Abdalla Elzedy
