Surface Laptop 7 (Qualcomm Snapdragon X Plus) not going into deep idle during Modern Standby, then hibernates too quickly

Question

Surface Laptop 7 (Qualcomm Snapdragon X Plus) not going into deep idle during Modern Standby, then hibernates too quickly

John Smith 20

Since June 2026 firmware update for my Surface Laptop 7, I noticed that often times it takes a while to wake up. I know the laptop goes into modern standby (S0) by default, and once the battery drains 5% during modern standby it hibernates.

I ran sleep study (powercfg /sleepstudy) and I see it hasn't gone into Deepest Runtime Idle Platform State (DRIPS) at all during standby:

r/Surface - Surface Laptop 7 (Qualcomm Snapdragon) draining battery quickly in Modern Standby then hibernating

The top offender is Qualcomm Bus Device (_SB.UR15). Any idea what this could be? I'm really seeing nothing useful on the sleep report to see what could be causing this.

r/Surface - FX Devices section

r/Surface - Srum Data section

I tried the Airplane mode, but the battery still drains during standby. I also tried Disconnected Standby mode (by running powercfg /setdcvalueindex scheme\_current sub\_none f15576e8-98b7-4186-b944-eafa664402d9 0), but that made no difference.

I'm on Windows 11 Pro 25H2 (26200.8655).

EDIT: I fixed this by going to Device Manager, and enabling the "Allow the computer to turn off this device to save power" option for Qualcomm FastConnect 7800 Dual Bluetooth Adapter.

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

S.Sengupta 32,111 MVP Volunteer Moderator

The problem device: _SB.UR15 is a UART bus, not a standalone peripheral — it's almost certainly carrying the Bluetooth radio's UART transport (or possibly GNSS/a sensor). The "Problem Device: TRUE" flag means Microsoft's own tooling has pinned it as what's blocking DRIPS. Airplane Mode/Disconnected Standby didn't help because those control network connectivity, not whether the UART driver is holding a power reference open.

Suggestions:

Device Manager → View → Devices by connection → expand _SB.UR15 to confirm what's actually attached to it.

Test: fully disable Bluetooth in Device Manager, then re-run powercfg /sleepstudy overnight. If UR15 clears up, Bluetooth's UART stack is confirmed as the cause.

Look for an updated Bluetooth UART Transport Driver or Qualcomm Bus Device package via Windows Update/Surface app.

Until fixed: leave Bluetooth off overnight or rely on Hibernate instead of Modern Standby.

File feedback via the Feedback specifically referencing the June 25, 2026, update and the System Manager Device/SCM version — these routes to the Surface engineering team faster than forum posts.

Watch for the next Surface Laptop 7 firmware release — regressions like this in the System Manager layer are usually caught and patched within one or two cycles once enough sleep-study reports come in.

In the meantime, using Hibernate instead of relying on Modern Standby is your most reliable workaround, since it sidesteps the DRIPS/power-state issue entirely.

John Smith 20 Reputation points

2026-07-27T00:29:15.7866667+00:00

Thank you so much.

I think I found the device that corresponds to _SB.UR15, but there's nothing showing under it. I think it's this:

When I open that one and go to Details - Property - BIOS device name, I see the following:

It wasn't recently updated, either:

Am I looking up the correct device here? Thank you.
S.Sengupta 32,111 Reputation points MVP Volunteer Moderator

2026-07-27T10:54:36.1766667+00:00
Good find — the Details tab confirming BIOS device name: _SB.UR15 is a solid match against the offender in your sleep study. Nothing shows nested under it — but that's expected in the default "Devices by type" view, which doesn't show ACPI hierarchy.

Next step : Switch to View → Devices by connection in Device Manager to see what, if anything, is actually attached under _SB.UR15 which would point squarely at the System Manager/firmware update as the cause. Devices by connection shows the real physical/logical hierarchy: which device sits on top of which bus, and what's plugged into each one. So instead of a flat list of seven identical "Qualcomm(R) Bus Device" entries, you'd see something like:

ACPI x64-based PC

└─ _SB.UR0 (Qualcomm Bus Device)

└─ [whatever's attached to UART 0]

└─ _SB.UR15 (Qualcomm Bus Device)

└─ [whatever's attached to UART 15] ← this is what we need to see

Workaround in the meantime: Rely on Hibernate rather than Modern Standby and send the feedback as I mentioned earlier.
John Smith 20 Reputation points

2026-07-28T15:59:41.2566667+00:00

Thank you so much. Unfortunately, even in the Devices by connection view, I don't see anything under the Qualcomm Bus Device

Under Drivers by device view, I can see oem244.inf (qcuart8380.inf) under the corresponding Bus Device. Does this provide any hint as to what's causing the sleep issue?
John Smith 20 Reputation points

2026-07-28T16:48:15.55+00:00

Btw, I just tried disabling Qualcomm Bluetooth UART Transport Driver, and rebooted. Now, I see it sleeps properly.
S.Sengupta 32,111 Reputation points MVP Volunteer Moderator

2026-07-29T09:44:27.1433333+00:00

That confirms it — great diagnostic work, and the new sleep study is a clean result: 98% low-power state time, actual bars showing up in the DRIPS histogram at the 8m and 16m buckets. That's a complete turnaround from the flat histogram you started with.

Root cause: The UART bus (_SB.UR15) is enumerated by Qualcomm's generic bus driver (qcuart8380.inf). The Bluetooth UART Transport Driver binds to that port at the software/driver level (not as a hardware child device), so it never appeared in "Devices by connection." That binding kept a power reference open on the UART, blocking DRIPS — regardless of whether Bluetooth was actually transmitting, which is why Airplane Mode/Disconnected Standby never helped.

Tradeoff: Bluetooth is now off (no wireless mouse/keyboard/headphones) in exchange for proper sleep.

Check for a driver update. Since the regression tracks with the June 2026 update, Qualcomm/Microsoft may already be aware. Watch Windows Update / Surface app for a newer Bluetooth UART Transport Driver version specifically — once patched, you can re-enable it.

File Feedback Hub report now that you have a clean before/after sleep study — this is strong, specific evidence (exact driver, exact fix) that'll be far more actionable for Microsoft than a vague report.

If you need Bluetooth periodically, you could enable it only when needed and disable it again before closing the lid, though that's obviously not a long-term solution.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. Thanks.
John Smith 20 Reputation points

2026-07-29T14:54:12.17+00:00

Thank you. I found a way to make my laptop go into DRIPS without disabling bluetooth completely. In Device Manager, the "Allow the computer to turn off this device to save power" was not checked for Qualcomm FastConnect 7800 Dual Bluetooth Adapter. Once I checked this option, it seems to sleep properly, although it lost 3% battery (72% to 69%) during 8.5-hour sleep, which seems somewhat high.

Is it normal to see "SOC Subsystems" - "NoHwDrips.SOC" in red as shown below? Thank you.
S.Sengupta 32,111 Reputation points MVP Volunteer Moderator

2026-07-29T23:49:34.7866667+00:00

Your fix is solid and matches expected behavior for this hardware generation. The red NoHwDrips.SOC block is a known reporting quirk on Snapdragon X platforms rather than a new fault. If the 3%/8.5hr rate bothers you, it's still worth keeping an eye on future Surface firmware updates.