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.

This is most likely caused by the lack of compatibility of some legacy software to the Connected Standby function in SP3. MS has identified the issue and they released the Jan-15 firmware update trying to fix it. In my case, things got improved after this update, but not completely fixed. For example, my Kensington mouse driver gave the xHCI USB problem before the update, but not any more after the update. However, I still encounter the xHCI USB issue from time to time, for example, when opening some (not all) flash enabled websites using Google Chrome, the xHCI USB may reappear. and I have to consider if flash+chrome is the culprit in this case. Maple 18 also seems can cause this issue. SP3 is now really becoming a pain in the **** because except the the mysterious xHCI USB problem, there is also the flickering external screen problem, miracast problem, disabled wireless AP etc.etc.......

I think I have found out, at least in my case, the culprit. I should say that I started all over again - for the second time! - doing a full restore of the original Surface Pro 3 image. I then decided to be extremely methodic about what I installed, to keep it to a minimum and I saved a restore point before each installation so I could revert back when necessary. So I first ran Windows Update a couple of times, installing everything recommended until there were no more updates required. I then installed Office 365. I then installed a baseball simulation game software called OOTP (I'm a big baseball fan...). I waited one day between each installation, and always saving a restore point at every step. I also installed a password manager add-on to Internet Explorer (LastPass). And that was it for 2 days. Connected Standby worked really, with often less than 2-3% of battery charge lost over a 4h connected standby period. But yesterday night, I had to connect remotely to my work network. My company uses Citrix, so I installed the Citrix receiver and did some work. Today, in 3 different Connected Standby sessions, I noticed I was losing significant battery charge (23% in 4 hrs). The sleepstudy report revealed that the dreaded xHCI USB (\_SB.PCI0.XHC) was again going crazy like there was no tomorrow... So I restored the save point I had taken before installing Citrix...Guess what? The next Connected Standby session is showing all green, not losing a single percent of charge in one hour with the xHCI USB controller very quiet at 0% active time. So Citrix doesn't seem to play nice with Connected Standby. It's a bit of a bummer that Citrix does that... I guess I'll have to uninstall and uninstall the Citrix receiver every time I need to connect to work (which fortunately only happens once a month). I will continue to report, crossing my fingers that it's really Citrix.

The workaround in this link works and will save you reinstalling Citrix Receiver. (Citrix say there is no functionality loss by implementing this workaround.) http://support.citrix.com/article/CTX200347?_ga=1.205814099.1916225896.1423630939

Thanks russellca, will check it out.

The workaround in this link works and will save you reinstalling Citrix Receiver. (Citrix say there is no functionality loss by implementing this workaround.) http://support.citrix.com/article/CTX200347?_ga=1.205814099.1916225896.1423630939 Thanks again russellca for this. Citrix indeed acknowledges that current version 4.2 of Citrix Receiver is causing an excessive use of USB power. I didn't do exactly what they recommended because I didn't want to mess in the Windows registry. Instead, I downloaded the previous 4.1 version of the Citrix receiver which does not has this faulty behaviour. I installed it, used it and get the SP3 on Connected Standy for more than 3 hours with sleepstudy report showing everything green and only a 3% battery decrease.

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

2015-02-25T02:52:18+00:00

This is most likely caused by the lack of compatibility of some legacy software to the Connected Standby function in SP3. MS has identified the issue and they released the Jan-15 firmware update trying to fix it. In my case, things got improved after this update, but not completely fixed.

For example, my Kensington mouse driver gave the xHCI USB problem before the update, but not any more after the update.

However, I still encounter the xHCI USB issue from time to time, for example, when opening some (not all) flash enabled websites using Google Chrome, the xHCI USB may reappear. and I have to consider if flash+chrome is the culprit in this case. Maple 18 also seems can cause this issue.

SP3 is now really becoming a pain in the **** because except the the mysterious xHCI USB problem, there is also the flickering external screen problem, miracast problem, disabled wireless AP etc.etc.......
Was this answer helpful?

0 comments No comments
Anonymous

2015-03-01T00:59:45+00:00

I think I have found out, at least in my case, the culprit.

I should say that I started all over again - for the second time! - doing a full restore of the original Surface Pro 3 image. I then decided to be extremely methodic about what I installed, to keep it to a minimum and I saved a restore point before each installation so I could revert back when necessary.

So I first ran Windows Update a couple of times, installing everything recommended until there were no more updates required. I then installed Office 365. I then installed a baseball simulation game software called OOTP (I'm a big baseball fan...). I waited one day between each installation, and always saving a restore point at every step. I also installed a password manager add-on to Internet Explorer (LastPass). And that was it for 2 days. Connected Standby worked really, with often less than 2-3% of battery charge lost over a 4h connected standby period.

But yesterday night, I had to connect remotely to my work network. My company uses Citrix, so I installed the Citrix receiver and did some work. Today, in 3 different Connected Standby sessions, I noticed I was losing significant battery charge (23% in 4 hrs). The sleepstudy report revealed that the dreaded xHCI USB (\_SB.PCI0.XHC) was again going crazy like there was no tomorrow...

So I restored the save point I had taken before installing Citrix...Guess what? The next Connected Standby session is showing all green, not losing a single percent of charge in one hour with the xHCI USB controller very quiet at 0% active time. So Citrix doesn't seem to play nice with Connected Standby.

It's a bit of a bummer that Citrix does that... I guess I'll have to uninstall and uninstall the Citrix receiver every time I need to connect to work (which fortunately only happens once a month).

I will continue to report, crossing my fingers that it's really Citrix.
Was this answer helpful?

0 comments No comments
Anonymous

2015-03-01T10:47:18+00:00

The workaround in this link works and will save you reinstalling Citrix Receiver. (Citrix say there is no functionality loss by implementing this workaround.)

http://support.citrix.com/article/CTX200347?_ga=1.205814099.1916225896.1423630939
Was this answer helpful?

0 comments No comments
Anonymous

2015-03-01T14:18:19+00:00

Thanks russellca, will check it out.
Was this answer helpful?

0 comments No comments
Anonymous

2015-03-01T20:29:26+00:00

The workaround in this link works and will save you reinstalling Citrix Receiver. (Citrix say there is no functionality loss by implementing this workaround.)

http://support.citrix.com/article/CTX200347?_ga=1.205814099.1916225896.1423630939

Thanks again russellca for this. Citrix indeed acknowledges that current version 4.2 of Citrix Receiver is causing an excessive use of USB power. I didn't do exactly what they recommended because I didn't want to mess in the Windows registry. Instead, I downloaded the previous 4.1 version of the Citrix receiver which does not has this faulty behaviour. I installed it, used it and get the SP3 on Connected Standy for more than 3 hours with sleepstudy report showing everything green and only a 3% battery decrease.
Was this answer helpful?

0 comments No comments