BeeJ said:
Win7 Pro latest updates. PC 3.2GHz with 8GRAM
Using Avast virus scanner. MS 5000 Kbd and Mouse.
This started a few days ago on a system that was newly installed about
three weeks ago.
The mouse sometimes skips as I attempt to move it across the screen.
This will happen for a few seconds, stop skipping, the do it again.
There seems to be no relationship to what application is running: One
of several browsers, Windows Live Mail etc.
I am running Process Explorer and see nothing that looks out of the
ordinary to me. CPU is at over 85% all the time and 96% when "idle" (me
not doing anything.
I opened MSConfig and don't see anything strange there.
If I have only Process Explorer open, I have no skipping.
If I open most anything else the skipping resumes on and off.
What should I look for?
To make a mouse skip, it could be a bad mouse, but it could also be
that the system is unresponsive for fractions of a second at a time
(and then the mouse cannot be serviced, and mouse events passed to the UI).
This could take the form of staying within the kernel, doing driver
level stuff. It could even be an issue with the mouse driver, for that
matter. But my theory would be, the skipping has a root cause of
something making the system "busy". A hardware fault, causing an excessive
number of interrupts could do it. Or AV software, that works at such a
low level, as to be almost virus-like itself.
*******
Do you have a significant Delay Procedure Call (DPC) component in
the graph ? It should be a line in the graph near the top.
Also, when using Task Manager in Windows 7, you have to click the button
to get it to show all processes running. The summary may not be enough.
If you had a hardware interrupt problem, you would expect a DPC to be
queued for each interrupt. (That's an assumption on my part.) So even
if you couldn't see an actual interrupt rate, you could guess at it
by looking at DPC. With little activity on the system, DPC won't go to
zero, because some parts of the machine run interrupts at a low regular
rate. For example, if I play a 3D game, and alt-tab out of the game,
the video card appears to still be doing something, because I can
see up to a couple thousand interrupts per second from it. With no
game playing, the rate should be lower than that.
Some users have trouble determining whether the processor is "busy" or
"idle", due to the Idle Task. The Idle Task is a process mechanism, that
measures how often the CPU is available to do work. The more time that the
Idle Task can run, the more idle the system is. And that's how they measure
%CPU usage, with the Idle Task. The Idle Task itself, after a small bit of
housekeeping, typically puts itself to sleep, helping to save on power
usage. So when you see a high value for the Idle Task, it's not preventing
other things from running.
There are ways, for a computer to use up cycles, without much to show for it.
If you can manage to stay within the Kernel, busy doing something, then the
processor cycles can go missing, with little to see. Drivers live down there.
But the cleanup portion of interrupt handling, is queued up as a DPC at user
level, so the DPC rate is visible evidence of that portion of a driver. And
Kernels are usually pretty carefully written, to reduce the time spent in
the kernel as overhead. In order to keep the system responsive, or support
true "Real Time" priority, the kernel has to be designed to get out of the way.
Things like AV programs, they can "get into a knife fight" with malware,
and that can cause a system to become very busy. When I had a Kaspersky
subscription, I got to witness that a few times (mainly when a Sysinternals
program would try to probe the system).
In an ideal world, software "profilers" would be easy to use, and allow
someone working on a system, to see where the system time is spent. The only
thing a system profiler might not see, is things like SMM. The BIOS has
a mechanism, to execute code on a running system, in such a way that the
OS can't "see" what it's doing. When a System Management Interrupt is raised,
the OS is effectively pre-empted, and the SMM code in the BIOS runs. This
could happen for very short intervals, say, 30 times a second. Some retail
motherboards use such an interval, to adjust the number of phases running
on the CPU VCore switching regulator. (Installing an "EPU driver" or the like,
may be part of that.) The "DPC Latency" program worked on older systems, to
allow measuring the amount of SMM activity, by noting the inability of
DPC queued items to get serviced promptly. So if there are DPC Latency spikes,
they could be caused by SMM. I've also seen the initiation of a 3D game causes
a huge DPC latency spike, and that means I might experience a computer time
keeping effect from the "lost time" caused by that. But you'd have to start
thousands of 3D games a day, for it to become an issue.
So, there are things you can see, and things you can't see. Some operations
on the computer, have a "higher priority" than the user activity, or, they
may only be observed by inference. Even with a good software profiler, you
can't actually be guaranteed of a full system trace. Only a hardware logic
analyzer gives you some chance of observing what is going on (a logic analyser
could see SMM, or perhaps watch SMM code being pulled from flash), and with
multi-core processors, it would be pretty difficult to even get a full picture
by watching addresses being emitted on the system bus. It was hard enough
to do that, when the processor only had one core. Turning off caches (L1/L2/L3)
helps increase external bus activity, improving the ability to see what is
going on, but at the expense that the system dynamics are ruined. So the very
thing you're trying to study, could have its timing so thrown off, as for the
study to be useless. (Imagine having a 3D game run at one frame per second,
while you're trying to use the logic analyzer. A user playing a game on the
machine, while you're debugging, would be pretty frustrated at one frame
per second. With caches disabled, the CPU has very poor performance
characteristics.)
*******
You need to determine:
1) Whether "CPU is at over 85%" is for real. Some users confuse the
busy or idle state of their system. It's important to verify the
system is really that busy, as a starting point.
2) If (1) is true, figure out what is making the CPU over 85% busy.
Paul
