High CPU SVCHost.exe - Logitech the Culprit

Monopoly money comes in many flavors: 7, Vista, XP, 2K, ME, 98, etc.

Moderators: Flying Fox, Ryu Connor

High CPU SVCHost.exe - Logitech the Culprit

Postposted on Fri Feb 01, 2013 3:49 am

I've suddenly been getting spikes in CPU usage out of no where. Its always VERY prevalent at windows start-up. I assumed it was from my very poor/failed attempt at getting my Sabertooth P67 to allow me to use the Marvell controller do SSD Caching, a function I now understand is not remotely possible with this particular board. It was reported in other P67 series chipsets, but this particular sub version of the Marvell controller does not support certain RAID configurations (the other controllers on-board do). Hence its in-ability to use RAID trickery to provide SSD Caching.

Anyway... shortly after all of that I had issue, reverted controller drivers back, ect. Well I kept thinking this poor performance I had was related to really **** controller drivers, so I switched my OS over to another SATA port and things were still just as bad.

So the already long story short... I ran Process Explorer and found SVCHost and WmiPrvSE.exe both jumping up and down in CPU usage, anywhere from 10-20%. I watched as my i5-2500k (Stock) hit 50-80% CPU use while the RAM stuck at 11-13% (16GB). Opening up SVCHost showed an odd thread listed as
Code: Select all
ntdll.dll!rtlValidateHeap+0x170


This line repeats 5-10 times and only one of them (the newest) has the majority of the SVCHost's CPU use under the threads. Oddly enough, I did a LOT of reading over the course of the last 4-5 hours and found someone mentioning having a lot of Logitech stuff running. I do have a Logitech Keyboard (original G15) and a G5 mouse. Other posters noticed the OP's SVCHost mentioned PNP, which was apparently odd. Well so does mine...

Now here is where it gets funny and odd. I decided to move use the volume button on my keyboard to see what reaction it would have and....... The SVCHost CPU Use went out the roof. The system idle went from 4% total CPU use to 50 and 60%. The thread that shot out of the roof was the
Code: Select all
ntdll.dll!rtlValidateHeap+0x170


So I'm going to remove the drivers that run this stupid keyboard and see what happens. But I figured I'd share this for any poor SoB Google searching a fix for this issue.

Here is an example thread stack when I use the volume adjustment button and spike the heck out of the Plug and Play service/threads.

Code: Select all
ntoskrnl.exe+0x81e7a
ntoskrnl.exe+0x74a32
ntoskrnl.exe+0x865d3
ntoskrnl.exe+0x363197
ntoskrnl.exe+0x6a236
ntoskrnl.exe+0x7e253
ntdll.dll!ZwWaitForWorkViaWorkerFactory+0xa
ntdll.dll!RtlValidateHeap+0x3bb
kernel32.dll!BaseThreadInitThunk+0xd
ntdll.dll!RtlUserThreadStart+0x21
"I think there is a world market for maybe five computers."
Thomas Watson, chairman of IBM, 1943

i5-2500K|Asus P67 Sabertooth|16GB Corsair 1600|MSI 7850 2GB|250gb Evo 840|Corsair 400R|ET750w PSU|Logitech G5|Dell 2420L|Corsair Vengeance 1300
Welch
Minister of Gerbil Affairs
Gold subscriber
 
 
Posts: 2581
Joined: Thu Nov 04, 2004 4:45 pm
Location: Fairbanks, Alaska

Re: High CPU SVCHost.exe - Logitech the Culprit

Postposted on Fri Feb 01, 2013 5:40 am

You have this behavior after uninstalling the Logitech drivers? I don't trust their drivers.
If your cause is just and good, argue that it is just and good, not just inevitable.
My Johnson
Gerbil Elite
 
Posts: 655
Joined: Fri Jan 24, 2003 2:00 pm
Location: Dystopia, AZ

Re: High CPU SVCHost.exe - Logitech the Culprit

Postposted on Fri Feb 01, 2013 9:07 am

Sounds like someone forgot to turn off the debugger options when compiling a release build...
(this space intentionally left blank)
just brew it!
Administrator
Gold subscriber
 
 
Posts: 36881
Joined: Tue Aug 20, 2002 9:51 pm
Location: Somewhere, having a beer

Re: High CPU SVCHost.exe - Logitech the Culprit

Postposted on Fri Feb 01, 2013 6:15 pm

Yep, still getting it after uninstalling all of their software, removing drivers, disabling drivers, you name it.

JBI, this is a full OEM build on Win 7, how exactly would debugger mode have become enabled without my doing, because I've never turned debugging on. I have on the other hand enabled driver signature debugging at one point in time.... and I don't recall if I shut it back off now that you mention it.
"I think there is a world market for maybe five computers."
Thomas Watson, chairman of IBM, 1943

i5-2500K|Asus P67 Sabertooth|16GB Corsair 1600|MSI 7850 2GB|250gb Evo 840|Corsair 400R|ET750w PSU|Logitech G5|Dell 2420L|Corsair Vengeance 1300
Welch
Minister of Gerbil Affairs
Gold subscriber
 
 
Posts: 2581
Joined: Thu Nov 04, 2004 4:45 pm
Location: Fairbanks, Alaska

Re: High CPU SVCHost.exe - Logitech the Culprit

Postposted on Fri Feb 01, 2013 11:12 pm

Welch wrote:JBI, this is a full OEM build on Win 7, how exactly would debugger mode have become enabled without my doing, because I've never turned debugging on.

Not you, the developers at Logitech. Based on your original post it seemed like they may have accidentally distributed drivers with debug code still in them. I'm pretty sure RtlValidateHeap is a diagnostic that is typically used to troubleshoot buggy code with heap corruption issues. Shouldn't be spending so much time in it in a release build.

But if the problem is still there after uninstalling the drivers, I guess that's not it.

Edit: Since you mention WmiPrvSE as one of the processes eating CPU, you may want to have a look at this:
http://blogs.msdn.com/b/wmi/archive/200 ... llain.aspx
(this space intentionally left blank)
just brew it!
Administrator
Gold subscriber
 
 
Posts: 36881
Joined: Tue Aug 20, 2002 9:51 pm
Location: Somewhere, having a beer

Re: High CPU SVCHost.exe - Logitech the Culprit

Postposted on Sun Feb 03, 2013 3:16 am

Thanks for the info JBI, I'll add that to my list of my shortcuts to filtering out useless info in event logs. I enabled logging for WMI and since then (of course) I can't seem to recreate the issue and not even a warning shows up for WMI. System seems to take about 15 seconds to load into Windows after password, and about another 30-40 seconds to load all modules, but that's what you get when your running a scrounged HDD. I've got the Windows CPU/Memory gauge and HarvestApp running, nothing else major at start-up.

I DID however.... reset the driver verifier I was using while troubleshoot a BSOD issue I was having roughly 2 weeks or so ago. I wonder if having the driver verifier set to verify was causing me this additional grief. I should have thought of this before hand but it all happened pretty seamlessly to the point that it seemed like one big issue. Since then I've installed updated SATA controller drivers and even after those had issue with high cpu usage, but no more lock ups or BSODs. So I think it was a combo of a corrupt SATA driver and the verifier being enabled to initially determine that the SATA controller drivers were screwed. I just assumed that with high disk use I was causing high CPU use thanks to some of the I/O from the drive being offloaded to other hardware due to me having corrupted drivers at the time.

So.... Its only been one day, but I'm assuming the issue is fixed. Seeing no more WMI heap threads popping up... YET. Mostly idle with Firefox open and typing this post, my i5-2500k is sitting at 1-2%.

Thanks for the new info and the unintentional reminder that I left verifier running.
"I think there is a world market for maybe five computers."
Thomas Watson, chairman of IBM, 1943

i5-2500K|Asus P67 Sabertooth|16GB Corsair 1600|MSI 7850 2GB|250gb Evo 840|Corsair 400R|ET750w PSU|Logitech G5|Dell 2420L|Corsair Vengeance 1300
Welch
Minister of Gerbil Affairs
Gold subscriber
 
 
Posts: 2581
Joined: Thu Nov 04, 2004 4:45 pm
Location: Fairbanks, Alaska

Re: High CPU SVCHost.exe - Logitech the Culprit

Postposted on Sun Feb 03, 2013 1:49 pm

Welch wrote:I wonder if having the driver verifier set to verify was causing me this additional grief.


It can. The driver verifier can expose bugs that would not be found under normal operation.
"Welcome back my friends to the show that never ends. We're so glad you could attend. Come inside! Come inside!"
Ryu Connor
Global Moderator
Gold subscriber
 
 
Posts: 3449
Joined: Thu Dec 27, 2001 6:00 pm
Location: Marietta, GA

Re: High CPU SVCHost.exe - Logitech the Culprit

Postposted on Sun Feb 03, 2013 2:00 pm

Note that verifier does state that if a driver has an error while verifier is active that it will BSOD, which I didn't have since I had removed all of the drivers and refreshed with versions directly from the manufacturer instead of Asus' website.

Any clue if the ValidateHeap thread is something indicative of the driver verifier running into a WMI request loop on a drivers behalf? WMI is not something I've ran across needing a large amount of troubleshooting for before this, not sure if that is a normal thread in a limited capacity to see.

After disabling verifier things went to what appears to be normal, if I use the Logitech volume it will spike the CPU up to 30% opposed to 60+ and it returns to normal much faster. So it almost sounds as if the drivers for the Logitech are still screwed and logging with verifier only made it worse as it attempted to read/verify and log each incident. I'm thinking that the Logitech software was querying the system every so often for information to update to the LCD screen that this keyboard has (which I don't really use anymore).
"I think there is a world market for maybe five computers."
Thomas Watson, chairman of IBM, 1943

i5-2500K|Asus P67 Sabertooth|16GB Corsair 1600|MSI 7850 2GB|250gb Evo 840|Corsair 400R|ET750w PSU|Logitech G5|Dell 2420L|Corsair Vengeance 1300
Welch
Minister of Gerbil Affairs
Gold subscriber
 
 
Posts: 2581
Joined: Thu Nov 04, 2004 4:45 pm
Location: Fairbanks, Alaska

Re: High CPU SVCHost.exe - Logitech the Culprit

Postposted on Sun Feb 03, 2013 2:52 pm

I do not authoritatively know the answer to your question. This is just an educated guess.

I can't find a reference to HeapValidate in the Driver Verifier documentation. That does not necessarily mean driver verifier doesn't leverage a HeapValidate test. Driver verifier does have targeted tests for determining if memory corruption has occurred and HeapValidate is a great tool for that purpose.

Given how driver verifier is set to work, it is my belief, that it would continue to loop HeapValidate looking for memory corruption (if you enabled the memory tests) until such time as the driver programmer or QA technician disabled the tool. The MSDN article above notes that HeapValidate tests when leveraged on multi-core (they use the classic term SMP) can "degrade performance". That certainly sounds like a possible euphemism for high CPU usage to me.

Given that your problem appears to stem from a USB device and interacting with the controls of the USB device is what causes the CPU spikes. I would be more apt to suspect that there is a polling problem with the system. If you have "overclocked" your USB ports to 500 or 1000Hz, you might consider setting them back down to 125Hz.
"Welcome back my friends to the show that never ends. We're so glad you could attend. Come inside! Come inside!"
Ryu Connor
Global Moderator
Gold subscriber
 
 
Posts: 3449
Joined: Thu Dec 27, 2001 6:00 pm
Location: Marietta, GA


Return to Windows

Who is online

Users browsing this forum: No registered users and 1 guest