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 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.

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've not experienced that issue before. What non modern windows apps are you installing? I generally install Office 365 Visio ResPAK Functions software Adobe Acrobat Pro None of these have caused my USB controller to max out at 100%.

I'm having the same issue of battery drain because of the dreaded xHCI USB (\_SB.PCI0.XHC) controller... When it started, I thought it was caused by an application I installed, so I did a full restore of the SP3. For 1 or 2 days, it seemed to be correct. The xHCI USB controller was always making the top offender list, but it was active only for 1% of the time so things were green. Then it started to be active 100% all the time in Connected Stanby... I can't identify why it started to do it again. What's worse, it is with a different set of applications as I had not re-installed that many apps yet. This thing must be driving like crazy because the SP3 case is getting noticeably hot. It basically makes Connected Standby rather worthless as it eats up the battery almost as fast as if you would be using the SP3. When you Google xHCI USB (\_SB.PCI0.XHC), a lot of hits come up with SP3 users complaining this is a battery hog. I'm hoping Microsoft is aware and actively working on this. I can't believe some Microsoft employees aren't using the SP3 and have not noticed this issue. In the meantime though, does anyone knows how to get more details of what is activating the USB controller? This thing can't decide to go crazy on its own, I assume it's activated by something. Perhaps I'm not reading the sleepstudy report correctly, but it doesn't give any clue about what is causing the USB controller it to run like this.

Thanks for the reply but I'm not using Citrix and am experiencing this 400-450 mw per hour drain on a vanilla and fresh install of windows 8.1. I'm installing the bear minimum of apps I use which is office and visio and a printer driver. It sounds like most people in this thread have issues relating to Citrix, perhaps I should start a new thread?

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-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-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-02-25T02:47:39+00:00
I've not experienced that issue before. What non modern windows apps are you installing?

I generally install
- Office 365
- Visio
- ResPAK Functions software
- Adobe Acrobat Pro
None of these have caused my USB controller to max out at 100%.
Was this answer helpful?

0 comments No comments
Anonymous

2015-02-25T01:52:20+00:00

I'm having the same issue of battery drain because of the dreaded xHCI USB (\_SB.PCI0.XHC) controller...

When it started, I thought it was caused by an application I installed, so I did a full restore of the SP3. For 1 or 2 days, it seemed to be correct. The xHCI USB controller was always making the top offender list, but it was active only for 1% of the time so things were green.

Then it started to be active 100% all the time in Connected Stanby... I can't identify why it started to do it again. What's worse, it is with a different set of applications as I had not re-installed that many apps yet. This thing must be driving like crazy because the SP3 case is getting noticeably hot.

It basically makes Connected Standby rather worthless as it eats up the battery almost as fast as if you would be using the SP3.

When you Google xHCI USB (\_SB.PCI0.XHC), a lot of hits come up with SP3 users complaining this is a battery hog. I'm hoping Microsoft is aware and actively working on this. I can't believe some Microsoft employees aren't using the SP3 and have not noticed this issue.

In the meantime though, does anyone knows how to get more details of what is activating the USB controller? This thing can't decide to go crazy on its own, I assume it's activated by something. Perhaps I'm not reading the sleepstudy report correctly, but it doesn't give any clue about what is causing the USB controller it to run like this.
Was this answer helpful?

0 comments No comments
Anonymous

2015-02-23T22:56:50+00:00

Thanks for the reply but I'm not using Citrix and am experiencing this 400-450 mw per hour drain on a vanilla and fresh install of windows 8.1.

I'm installing the bear minimum of apps I use which is office and visio and a printer driver. It sounds like most people in this thread have issues relating to Citrix, perhaps I should start a new thread?
Was this answer helpful?

0 comments No comments