Among the handful of machines I use on a daily basis is a Surface Pro 4 that’s mostly sat docked at my desk all day since I finally upgraded my 2011 to the newest 2018 MacBook Pro. Lately, I’ve noticed it behaving poorly in sleep mode. This morning, I sat down to figure out why.
Windows includes a command line tool called “powercfg.exe” for managing and testing all sorts of power-related things. One utility is
powercfg.exe /batteryreport, which creates a lovely html page with power events, graphs, and a bit of analysis, in much the same way lots of current phones provide such information. You can generate a report and have a look for yourself by running the command above in powershell.
You can already see something odd in that screenshot, although it might not be super obvious – my machine seems to be going between Connected standby and Active modes a lot.
Modern Windows portables, certainly including the Surface Pro lineup, implement a new power architecture known as “modern standby.” This includes a power state called “connected standby,” in which the machine is 99.9% asleep, but is able to wake up quickly and periodically to handle background tasks. Where “sleep” of old meant “completely inactive, but using a little bit of power to keep the memory state so the machine boots fast,” connected standby consumes comparable power, but is able to maintain network connectivity, process events, and so on. It’s the windows equivalent of what your iPhone does when you turn off the screen, consuming very little power but maintaining its ability to get notifications, receive calls, sound alarms, and so on.
On machines that use modern standby, powercfg.exe has a fantastic diagnostic utility called SleepStudy. You can read all about it at this documentation link. It’s a bit like the battery report above, but on super-steroids. It tells you about every state transition with a whole bunch of supporting information, and everything is in one searchable, interactive html file output. You can generate your own with (again, in powershell)
powercfg /sleepstudy. Note: I think you need to be running powershell as administrator for this, so you probably want to cd to somewhere other than the System32 directory, as the report will be generated in the current dir.
The top of my report isn’t very interesting. Scroll down and we see some VERY odd things:
So what’s going on here? This list gives us a bunch of useful info: the power state, when it started, how long it lasted, and also some info about what happened to energy during that state. The listing above is pretty legible since I was at 100% and plugged in the whole time. What first strikes me as odd here is the duration column: the machine switches between Modern Standby and Active over and over, spending ~30s in Active and ~5s in Modern Standby every time. That’s messed up, for sure. I didn’t realize it at first, but those red lines are also a pretty great clue: when the machine DOES spend real time in Modern Standby, it’s actually spending 0% of that time in truely low power mode. SOMETHING is keeping the machine “awake,” even during sleep.
What’s coolest about this table is that you can just click on any line to scroll down in the page to a more detailed readout. I started with one of the 4-second Modern Standby entries
The detailed OS State Data is mostly gibberish to me, and entirely un-illuminating in my situation. Given a different root cause, it might be interesting. It does have some intelligible info, like the “lid” was open during this time. What’s more interesting is the duration, paired with “entry reason” and “exit reason.” Entry reason was “Video Idle Timeout,” which makes complete sense – the machine was in Active mode for 30s before, presumably displaying the login screen, then after 30s of inactivity it goes to sleep. The Exit Reason “Input Keyboard” doesn’t – I’m sure I wasn’t sitting there pressing keys to wake up the machine every 30+4 seconds. But it does point to some kind of possible USB, possible wireless keyboard, possible mouse issue. Of course, I kind of already suspected a USB device, since that’s all that’s plugged in, besides a monitor.
It got much more interesting when I clicked one of the red lines.
There’s a huge wealth of information in these longer log entries, presumably because the info gets discarded for too short a state. There’s almost too much to describe – that “…” on the right of the line expands to a ton more state timing info. But what immediately jumped out at me here is the “Top Offenders” section – things “offending” Modern Standby seem exactly like what I’m looking for. A couple look innocuous, probably because they’re green colored. The network controller in particular seems to be taking up the most time of these, which makes sense. Slightly less innocuous is the orange line, of type “Activator.” I have no idea what “BI” means, but if we drop that list down, it’s a bunch of software traces that seem to indicate what the machine was doing during those active blips – “Microsoft.Windows.ContentDeliveryManager, Microsoft.Windows.Cortana, Microsoft.Windows.Photos.” All of those things seem like reasonable background task masters. Photo syncing. Notification delivery. Spying on my microphone. Normal stuff.
That 92% active USB controller seems like a real problem though. Some USB device is keeping the machine awake for 92% of it’s attempted sleep cycle. Bingo.
Expanding all the problem children all the way down, the last device in the chain is a “USB Mass Storage Device.” I already know what this is, because there’s only one such thing plugged in – a Plugable memory card reader with no cards in it. Just for giggles, I opened Device Manager to have a look. Sure enough, same USB VID&PID.
Why a memory card reader with nothing in it is causing keyboard events that wake up the machine, I don’t know. Driver incompatibility with a new Windows update? Maybe it’s not a “keyboard” event at all and that’s a quirk of how SleepStudy reports state change? Maybe my card reader is secretly spying on me. Who knows.
I unplugged it and now my machine sleeps soundly again.