I'm interested to know what other users tend to see when running the "powercfg /sleepstudy" tool on their Surface Pro 3s (as per http://blogs.windows.com/windows/b/windowsexperience/archive/2014/06/26/sleep-study-diagnose-what-s-draining-your-battery-while-the-system-sleeps.aspx ). I'm finding that all my "InstantGo" sessions have a drain rate of between 1200 and 2200mW, which can correspond to between 10% and 20% of the battery drain in the 4 hours before the machine hibernates. Looking at the culprits, almost all the sessions show the following device running for the entire "sleep" period: USB xHCI Compliant Host Controller (\_SB.PCI0.XHC) Fx Device 100% 4:00:00 Is this expected? FWIW, I tend to leave the keyboard cover connected during sleep. Sometimes (when the drain is at the high end of the range), I also see the following: Intel(R) HD Graphics Family (\_SB.PCI0.GFX0) Fx Device 100% 4:00:00 Interestingly, during the first few days I had the SP3, the graphics driver was appearing in every session of the sleep study report. More recently, though, it has stopped appearing. Recently I've been leaving the Surface at the start screen rather than the Desktop, so this may be related - is there a recommendation about coming out of the Desktop before going to "sleep" I also never see anything in the "DRIPS histogram" - should I? What are other people seeing? On a related note, does anyone know if there is a way of changing the time before the machine hibernates? For me, 2 hours (or even 1 hour) would probably be fine - if I'm actively going from one office to another, then the "instant" resume is great, but if I'm at home, leaving the machine for a while, then 4 hours is overkill.

Interestingly, last night was one of the first times I've seen an InstantGo session which didn't include the USB xHCI Compliant Host Controller (but it did include the HD Graphics at 100% activation and in 4 hours I lost 16% of my battery). If anyone is interested, my latest sleep study report can be seen at http://1drv.ms/1s1KZud.

I thought I'd share a bit more information here, which possibly answers my own question! The SP3 I've been using up until now is a machine for work, so has been upgraded to Windows 8.1 Enterprise and uses, among other things, DirectAccess for connection to our office. I've now got myself a second SP3 for home use which has not been "updated" by our IT department. This one appears to show significantly better performance during "sleep". So far, for example, there are always bits showing in the 32s "DRIPS" buckets and the batter drain per sleep period is minimal (with most sleep periods showing as either "green" or "amber" in the sleep study). So, based on this, it seems clear that my work unit is misbehaving - the questions then become "why" and "how can I stop it". Is there any way one can dig into more detail on exactly what could be causing my USB and graphics devices to be active so much during sleep?

Any Luck on your work device? I too am running a SP3 with Windows Enterprise, all the latest patches and firmwares, it's an i5 Model. This one is the primary troublemaker: USB xHCI Compliant Host Controller (\_SB.PCI0.XHC) I do not use DirectAccess, the only thing out of the ordinary I do use is a Display Link docking solution at work. At home where it should be sleeping, I just use the SP3 with the Type Keyboard attached, no usb dongles. justin.

Sadly no luck yet. Interestingly, my initial thought was that this was caused by the DisplayLink docking station. However, - I now use the MS docking station and have uninstalled the DisplayLink drivers - a colleague now has an SP3 (running Enterprise) which has never used the DisplayLink dock and he also sees the xHCI Compliant Host Controller as his top culprit when in standby. We tried disconnecting the type keyboard before sleeping to see if that had an effect, but the host controller still showed up at 100%. I'm guessing there is something weird going on with Windows 8.1 Enterprise, but it would be nice to see other input to this thread (either corroborating this idea or even someone from MS actually commenting on it!). Ed

We've been working with Microsoft to figure out some similar issues we've seen on the SP3. 2955769 is an important hotfix to have installed. It is part of 2955164 which is a rollup of hotfixes. After that is installed, we are also running a bat file with the following commands to update power settings in our corporate image. The 14400 value corresponds to the 4 hours before connected standby is supposed to transition to sleep. Evidently there is a minimum time this can be set to, but we haven't figured out what that is yet. powercfg /setdcvalueindex SCHEME_CURRENT e73a048d-bf27-4f12-9731-8b2076e8891f 7398e821-3937-4469-b07b-33eb785aaca1 14400 powercfg /setacvalueindex SCHEME_CURRENT e73a048d-bf27-4f12-9731-8b2076e8891f 7398e821-3937-4469-b07b-33eb785aaca1 14400 REM sets CS Battery Saver Trip Point to 100 powercfg /setdcvalueindex SCHEME_CURRENT e73a048d-bf27-4f12-9731-8b2076e8891f 1e133d45-a325-48da-8769-14ae6dc1170b 100 powercfg /setacvalueindex SCHEME_CURRENT e73a048d-bf27-4f12-9731-8b2076e8891f 1e133d45-a325-48da-8769-14ae6dc1170b 100 REM sets the CS Battery Saver Action to hibernate powercfg /setdcvalueindex SCHEME_CURRENT e73a048d-bf27-4f12-9731-8b2076e8891f c10ce532-2eb1-4b3c-b3fe-374623cdcf07 001 powercfg /setacvalueindex SCHEME_CURRENT e73a048d-bf27-4f12-9731-8b2076e8891f c10ce532-2eb1-4b3c-b3fe-374623cdcf07 001

What should "sleepstudy" show for a Surface Pro 3

Anonymous

I'm interested to know what other users tend to see when running the "powercfg /sleepstudy" tool on their Surface Pro 3s (as per http://blogs.windows.com/windows/b/windowsexperience/archive/2014/06/26/sleep-study-diagnose-what-s-draining-your-battery-while-the-system-sleeps.aspx).

I'm finding that all my "InstantGo" sessions have a drain rate of between 1200 and 2200mW, which can correspond to between 10% and 20% of the battery drain in the 4 hours before the machine hibernates.

Looking at the culprits, almost all the sessions show the following device running for the entire "sleep" period:

USB xHCI Compliant Host Controller (\_SB.PCI0.XHC)	Fx Device	100%	4:00:00

Is this expected? FWIW, I tend to leave the keyboard cover connected during sleep.

Sometimes (when the drain is at the high end of the range), I also see the following:

Intel(R) HD Graphics Family (\_SB.PCI0.GFX0)	Fx Device	100%	4:00:00

Interestingly, during the first few days I had the SP3, the graphics driver was appearing in every session of the sleep study report. More recently, though, it has stopped appearing. Recently I've been leaving the Surface at the start screen rather than the Desktop, so this may be related - is there a recommendation about coming out of the Desktop before going to "sleep"

I also never see anything in the "DRIPS histogram" - should I?

What are other people seeing?

On a related note, does anyone know if there is a way of changing the time before the machine hibernates? For me, 2 hours (or even 1 hour) would probably be fine - if I'm actively going from one office to another, then the "instant" resume is great, but if I'm at home, leaving the machine for a while, then 4 hours is overkill.

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments

82 answers

Anonymous

2014-07-03T09:24:34+00:00

Interestingly, last night was one of the first times I've seen an InstantGo session which didn't include the USB xHCI Compliant Host Controller (but it did include the HD Graphics at 100% activation and in 4 hours I lost 16% of my battery).

If anyone is interested, my latest sleep study report can be seen at http://1drv.ms/1s1KZud.
Was this answer helpful?

0 comments No comments
Anonymous

2014-07-14T08:15:06+00:00

I thought I'd share a bit more information here, which possibly answers my own question!

The SP3 I've been using up until now is a machine for work, so has been upgraded to Windows 8.1 Enterprise and uses, among other things, DirectAccess for connection to our office.

I've now got myself a second SP3 for home use which has not been "updated" by our IT department. This one appears to show significantly better performance during "sleep". So far, for example, there are always bits showing in the 32s "DRIPS" buckets and the batter drain per sleep period is minimal (with most sleep periods showing as either "green" or "amber" in the sleep study).

So, based on this, it seems clear that my work unit is misbehaving - the questions then become "why" and "how can I stop it".

Is there any way one can dig into more detail on exactly what could be causing my USB and graphics devices to be active so much during sleep?
Was this answer helpful?

0 comments No comments
Anonymous

2014-09-22T17:31:12+00:00

Any Luck on your work device?

I too am running a SP3 with Windows Enterprise, all the latest patches and firmwares, it's an i5 Model.

This one is the primary troublemaker:

USB xHCI Compliant Host Controller (\_SB.PCI0.XHC)

I do not use DirectAccess, the only thing out of the ordinary I do use is a Display Link docking solution at work.

At home where it should be sleeping, I just use the SP3 with the Type Keyboard attached, no usb dongles.

justin.
Was this answer helpful?

0 comments No comments
Anonymous

2014-09-22T17:44:07+00:00

Sadly no luck yet. Interestingly, my initial thought was that this was caused by the DisplayLink docking station. However,

- I now use the MS docking station and have uninstalled the DisplayLink drivers

- a colleague now has an SP3 (running Enterprise) which has never used the DisplayLink dock and he also sees the xHCI Compliant Host Controller as his top culprit when in standby.

We tried disconnecting the type keyboard before sleeping to see if that had an effect, but the host controller still showed up at 100%.

I'm guessing there is something weird going on with Windows 8.1 Enterprise, but it would be nice to see other input to this thread (either corroborating this idea or even someone from MS actually commenting on it!).

Ed
Was this answer helpful?

0 comments No comments
Anonymous

2014-09-23T12:05:33+00:00

We've been working with Microsoft to figure out some similar issues we've seen on the SP3. 2955769 is an important hotfix to have installed. It is part of 2955164 which is a rollup of hotfixes. After that is installed, we are also running a bat file with the following commands to update power settings in our corporate image. The 14400 value corresponds to the 4 hours before connected standby is supposed to transition to sleep. Evidently there is a minimum time this can be set to, but we haven't figured out what that is yet.

powercfg /setdcvalueindex SCHEME_CURRENT e73a048d-bf27-4f12-9731-8b2076e8891f 7398e821-3937-4469-b07b-33eb785aaca1 14400

powercfg /setacvalueindex SCHEME_CURRENT e73a048d-bf27-4f12-9731-8b2076e8891f 7398e821-3937-4469-b07b-33eb785aaca1 14400

REM sets CS Battery Saver Trip Point to 100

powercfg /setdcvalueindex SCHEME_CURRENT e73a048d-bf27-4f12-9731-8b2076e8891f 1e133d45-a325-48da-8769-14ae6dc1170b 100

powercfg /setacvalueindex SCHEME_CURRENT e73a048d-bf27-4f12-9731-8b2076e8891f 1e133d45-a325-48da-8769-14ae6dc1170b 100

REM sets the CS Battery Saver Action to hibernate

powercfg /setdcvalueindex SCHEME_CURRENT e73a048d-bf27-4f12-9731-8b2076e8891f c10ce532-2eb1-4b3c-b3fe-374623cdcf07 001

powercfg /setacvalueindex SCHEME_CURRENT e73a048d-bf27-4f12-9731-8b2076e8891f c10ce532-2eb1-4b3c-b3fe-374623cdcf07 001
Was this answer helpful?

0 comments No comments