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

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

H2SO4 said:

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.

kevindd992002 said:

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?

kevindd992002 said:

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

kevindd992002 said:

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?

H2SO4 said:

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.

H2SO4 said:

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 :)

H2SO4 said:

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 :)

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!

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

kevindd992002 said:

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.

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.

kevindd992002 said:

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.