Explorer.exe taking up 15-30% CPU usage when moving mou

[Antman]

I never really suspected Adobe was causing your CPU usage anomoly - with the possible exception of context menu concerns, as it may have pertained to the sustained spike.

You could try using all Vista drivers for chipset and USB devices, but that approaches nonsense.

I wasn't guessing when I posted:

It is not often that I disagree with my esteemed colleagues.

The CPU spike is caused by activity over the USB, which requires CPU time. Yes, your wireless mouse is USB.

You are observing a driver issue, one that may or may not be corrected in the future with a driver update - whether that driver is for your chipset, wi-fi, mouse, or any other USB device. Most historical reports of this anomoly remain unsolved.

For those people experiencing a "normal" spike, you are also affected by this driver issue. Is it a problem? Apparently not.

 

[H2SO4]

I already uninstalled Adobe Acrobat, and the explorer.exe cpu usage issue is still there.

If this were a USB issue, why is it not happening in Vista?

Troubleshooting high processor usage is best done with a profiler. Unfortunately, there's still no x64 build of KernRate (which is an uber-utility), but XPerf can do something very similar, albeit with more pain involved.

If you're still keen to troubleshoot, you might want to download the x64 build of the Windows Performance Toolkit (WPT):

Windows Performance Analysis Developer Center

Let us know when you've installed it and I or someone else here can show you how to use it to find the bits of Explorer.exe which are supposedly chewing your processor(s) when you move the mouse.

 

[kevindd992002]

Oh ok.. So it's just a driver issue which I don't know which of those drivers

 

[kevindd992002]

I already uninstalled Adobe Acrobat, and the explorer.exe cpu usage issue is still there.

If this were a USB issue, why is it not happening in Vista?

Troubleshooting high processor usage is best done with a profiler. Unfortunately, there's still no x64 build of KernRate (which is an uber-utility), but XPerf can do something very similar, albeit with more pain involved.

If you're still keen to troubleshoot, you might want to download the x64 build of the Windows Performance Toolkit (WPT):

Windows Performance Analysis Developer Center

Let us know when you've installed it and I or someone else here can show you how to use it to find the bits of Explorer.exe which are supposedly chewing your processor(s) when you move the mouse.

Thanks for the help I am keen in solving this.

Done installing it

 

[H2SO4]

Thanks for the help I am keen in solving this.

Done installing it

- Get ready with that mouse.
- From an elevated (run as admin) command prompt: xperf –on DiagEasy
- Start moving that mouse as fast as you can without accidentally throwing it out the window. Keep it going for at least 30 seconds. Note the start and end times as close as you can to the nearest second.
- On the same elevated command prompt: xperf –d CpuGoingNuts.etl
- Start the XPerf utility (start menu) and load up that ETL file you just created.
- Use that foldaway control on the left to select counters which you believe to be relevant... or zip up the ETL file and upload it here - I'd like to take a look. (There's nothing personal in it unless you're running processes whose names you'd rather not reveal.)

 

[kevindd992002]

That's weird, when I type: xperf –on DiagEasy , I get an error of:

Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\>xperf -on DiagEasy
xperf: error: NT Kernel Logger: Cannot create a file when that file already exis
ts. (0xb7).

Why is that?

 

[H2SO4]

That's weird, when I type: xperf –on DiagEasy , I get an error of:

Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\>xperf -on DiagEasy
xperf: error: NT Kernel Logger: Cannot create a file when that file already exis
ts. (0xb7).

Why is that?

Probably because you ran it a second time with the "-on" switch without first stopping and dumping ("-d"). Use xperf -stop and then start it again.

 

[kevindd992002]

That's weird, when I type: xperf –on DiagEasy , I get an error of:

Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\>xperf -on DiagEasy
xperf: error: NT Kernel Logger: Cannot create a file when that file already exis
ts. (0xb7).

Why is that?

Probably because you ran it a second time with the "-on" switch without first stopping and dumping ("-d"). Use xperf -stop and then start it again.

Done Here's the file:

RapidShare: 1-CLICK Web hosting - Easy Filehosting

 

[H2SO4]

Done Here's the file:

RapidShare: 1-CLICK Web hosting - Easy Filehosting

Sorry, my bad, the "DiagEasy" preset doesn't include something I need. Please do that one more time except start the logging this way instead:

xperf -on base

Then dump and save this way after reproing the high processor usage once again:

xperf -d baseProvider.etl

 

[kevindd992002]

Sorry just replied now.

Here is the corrected etl:

RapidShare: 1-CLICK Web hosting - Easy Filehosting

 

[H2SO4]

Not quite what I expected to see but that makes it more fun.

I need to look at the "mouse" utilisation in more detail because it's strangely user-mode, but in the meantime I've got a few questions for you:

1) It's possible that the periodic spike in Explorer.exe utilisation - the one you see even if you don't move the mouse - is linked to some sort of animated wallpaper or similar change that occurs very close to once every 10 seconds on your machine. Can you think of any reason why the majority of time during those spikes would be spent in JPG-related WindowsCodecs.dll functions?

2) What's RMclock.exe and why are you putting up with it chewing around 5% processor almost constantly?

3) Does the mouse-related processor weirdness (which is definitely not normal BTW) also happen if you boot the box to safe mode?


I might ask you to do another xperf run with slightly different settings, depending on your answers to some of the questions above. Thanks for experiencing an interesing problem

 

[kevindd992002]

Not quite what I expected to see but that makes it more fun.

I need to look at the "mouse" utilisation in more detail because it's strangely user-mode, but in the meantime I've got a few questions for you:

1) It's possible that the periodic spike in Explorer.exe utilisation - the one you see even if you don't move the mouse - is linked to some sort of animated wallpaper or similar change that occurs very close to once every 10 seconds on your machine. Can you think of any reason why the majority of time during those spikes would be spent in JPG-related WindowsCodecs.dll functions?

2) What's RMclock.exe and why are you putting up with it chewing around 5% processor almost constantly?

3) Does the mouse-related processor weirdness (which is definitely not normal BTW) also happen if you boot the box to safe mode?


I might ask you to do another xperf run with slightly different settings, depending on your answers to some of the questions above. Thanks for experiencing an interesing problem

Thank you for your time and help

1.) With regards to animated wallpaper, I tried using the most basic theme/background I could use in Win7 and the problem still occurs. So, I don't really know about the WindowsCodecs.dll But I have this program: http://shark007.net/win7codecs.html installed, could it be causing the problem?

2.) RMClock.exe is used to undervolt but I'm pretty sure it is not causing the problem since COMPLETELY uninstalling it yields the same high CPU usage.

3.) And lastly, I DON'T experience it in safe mode.

 

[H2SO4]

1.) With regards to animated wallpaper, I tried using the most basic theme/background I could use in Win7 and the problem still occurs. So, I don't really know about the WindowsCodecs.dll But I have this program: Shark007.net - Windows 7 Codecs installed, could it be causing the problem?

Did you have some sort of desktop animation running at the time you generated baseProvider.etl? Are you saying that both patterns - "mouse" and "10sec periodic spike" - still occur even after you change to a basic theme/background? Check out those graphs in the screenshot I posted; is the "10sec spike" the one you see in Task Manager when not moving the mouse?

2.) RMClock.exe is used to undervolt but I'm pretty sure it is not causing the problem since COMPLETELY uninstalling it yields the same high CPU usage.

I have no reason to link it directly to either the "mouse" or "10sec" patterns, but it's doing strange things and consuming around 5% of your processor all the time. It would be best if you didn't undervolt/overclock/otherwise_abuse the hardware during the investigation

3.) And lastly, I DON'T experience it in safe mode.

Very significant. Are _both_ patterns gone in safe mode? In other words, in safe mode there's no appreciable processor utilisation due to mouse movement, and no periodic spike even when you're not moving the mouse?

 

[kevindd992002]

Did you have some sort of desktop animation running at the time you generated baseProvider.etl? Are you saying that both patterns - "mouse" and "10sec periodic spike" - still occur even after you change to a basic theme/background? Check out those graphs in the screenshot I posted; is the "10sec spike" the one you see in Task Manager when not moving the mouse?

At the time of generation of baseProvider.etl, I had the Windows 7 mix running, so I guess you could consider that as desktop animation, yes.

And yes, the "mouse" and "10sec periodic spike" still occur EVEN changing to basic background.

And yes again, I confirmed the 10sec spike is the one I'm seeing in Task Manager when not moving the mouse.

I have no reason to link it directly to either the "mouse" or "10sec" patterns, but it's doing strange things and consuming around 5% of your processor all the time. It would be best if you didn't undervolt/overclock/otherwise_abuse the hardware during the investigation

Ok, I will get rid of that as of now

Very significant. Are _both_ patterns gone in safe mode? In other words, in safe mode there's no appreciable processor utilisation due to mouse movement, and no periodic spike even when you're not moving the mouse?

Yes BOTH patterns are gone in safe mode, confirmed

 

[H2SO4]

OK, can you please do one more xperf run in normal mode?

xperf -on PROC_THREAD+LOADER+INTERRUPT+DPC+PROFILE -stackwalk profile

And to stop it...

xperf -d withstack.etl

Thanks!

 

[kevindd992002]

Should I do that xperf run without RMClock already? And with basic background?

 

[H2SO4]

Should I do that xperf run without RMClock already? And with basic background?

Yes, please. No RMclock and no pretty changing pictures. Less noise in the logs makes it easier to understand what might be happening. Otherwise, it's like looking for a needle in a stack of needles.

 

[TGSoldier]

They really say patience is a virtue...

May the force be with you H2SO4...

 

[kevindd992002]

Here's the new file:

RapidShare: 1-CLICK Web hosting - Easy Filehosting

That's weird, the 10sec spike was gone when I removed the desktop animation and RMClock. I'm pretty sure that RMClock doesn't cause that 10sec spike since even before installing RMClock I had that prob.

 

[H2SO4]

That's weird, the 10sec spike was gone when I removed the desktop animation and RMClock. I'm pretty sure that RMClock doesn't cause that 10sec spike since even before installing RMClock I had that prob.

Not only that - have you noticed that your "mouse" explorer.exe processor utilisation is now 10%?

I'm going to hazard a guess that RMclock had a kernel-mode component (a driver) which forced the machine into a lower power state, thereby supposedly justifying "undervolting". What surprised me when I saw the first ETL was that most of the processor usage was in (legit) user-mode modules - shell32.dll, user32.dll... - all things that are supposed to happen when the mouse is moving. It was as if your computer was simply underpowered, and operations which ought to have finished quickly were taking too long. In other words, it was as if you were running a 486-66

This last data set, with RMclock gone, shows a much more acceptable 9.99% long-term average while you're cranking that mouse (see attached table and graph). The blue and red lines at the bottom of the graph constitute the processor utilisation incurred by the mouse actually "interrupting" to say that movement has happened, and the OS processing those notifications low down (DPCs). The rest of the 10% is made up of user-mode routines which notify the underlying windows of the pointer's new position and actually repaint the cursor.

The interrupt rate, and therefore the DPC and user-mode processing rates, are all proportional to your mouse DPI settings. On the core2 quad on which I'm typing this, setting the mouse to 400DPI causes the proc to stay under 5% during mouse movement, and cranking it all the way to its 2000DPI max leads to say 7-8% - it's doing far more work for a given mouse displacement.

My other guess is that RMclock wasn't running in safe mode, which is why your symptom was confined to normal boots - the box was faster in safe mode when it wasn't being artificially hobbled.