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.

I do have this issue as well - my Surface Pro 3 drains about 4% of battery every hour during sleep. I see USB xHCI Compliant Host Controller (\_SB.PCI0.XHC) 100% in sleepstudy.

Thanks for this... I do have KB2955164 installed (and have had since June) so don't think this is helping. It looks like the commands you're setting here are to do with transitions from one state to another (in other when to go from the "connected" standby to hibernate and when to hibernate based on low battery level). Personally, I've not had problems with the 4 hour transition to hibernate - I do hibernate as expected, just use up more battery than I'd like in that 4 hour period. That said, a colleague who has just had an SP3 reinstalled by our IT department is finding that it doesn't hibernate after 4 hours (it just runs the battery down all night), so this might be helpful for him.

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

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

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.

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-09-27T00:59:09+00:00

I do have this issue as well - my Surface Pro 3 drains about 4% of battery every hour during sleep. I see

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

100% in sleepstudy.
Was this answer helpful?

1 person found this answer helpful.

0 comments No comments
Anonymous

2014-09-23T12:14:55+00:00

Thanks for this...

I do have KB2955164 installed (and have had since June) so don't think this is helping.

It looks like the commands you're setting here are to do with transitions from one state to another (in other when to go from the "connected" standby to hibernate and when to hibernate based on low battery level).

Personally, I've not had problems with the 4 hour transition to hibernate - I do hibernate as expected, just use up more battery than I'd like in that 4 hour period. That said, a colleague who has just had an SP3 reinstalled by our IT department is finding that it doesn't hibernate after 4 hours (it just runs the battery down all night), so this might be helpful for him.
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
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-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