While I happen to be a kernel mode developer, the following scenario
happened to me independently of that and appears unrelated to my own code.
On a machine I manage (W2K w/SP4 4 CPUs) something is consuming a lot of
CPU in kernel mode, apparently in whatever process is doing general I/O
at the time. This obviously slows the machine down so I would like to
track down the offending driver/hardware.
However I am somewhat at a loss as to how to do that on a live system,
given that the offending code does not appear to use its own thread and
most tools I have found so far seem to be focused on user mode hogs or
on already knowing the offending driver.
Back when SoftICE still existed I would attack such problems on
single-CPU systems by popping up SoftICE from the keyboard repeatedly to
see which code would most frequently be running at interrupt time, but I
lack a WinDbg or other MS tool based method.
Any ideas from the group?
–
Jakob B?hm, M.Sc.Eng. * xxxxx@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right
Jakob Bohm wrote:
While I happen to be a kernel mode developer, the following scenario
happened to me independently of that and appears unrelated to my own
code.
On a machine I manage (W2K w/SP4 4 CPUs) something is consuming a lot
of CPU in kernel mode, apparently in whatever process is doing general
I/O at the time. This obviously slows the machine down so I would
like to track down the offending driver/hardware.
Microsoft have a sampling profiler which works for kernel mode called
“kernrate”. That should do precisely what you want.
MH.
Martin Harvey wrote:
Jakob Bohm wrote:
> While I happen to be a kernel mode developer, the following scenario
> happened to me independently of that and appears unrelated to my own
> code.
>
> On a machine I manage (W2K w/SP4 4 CPUs) something is consuming a lot
> of CPU in kernel mode, apparently in whatever process is doing general
> I/O at the time. This obviously slows the machine down so I would
> like to track down the offending driver/hardware.
>
Microsoft have a sampling profiler which works for kernel mode called
“kernrate”. That should do precisely what you want.
MH.
Thanks, I didn’t know there was a public tool for accessing the kernel
profiler.
It helped a lot, after I manually tracked down and eliminated the false
hits on the CPU sleeping loop just after Exi386InterlockedExchangeUlong
in ntoskrnl.
–
Jakob B?hm, M.Sc.Eng. * xxxxx@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right
Jakob Bohm wrote:
It helped a lot, after I manually tracked down and eliminated the
false hits on the CPU sleeping loop just after
Exi386InterlockedExchangeUlong in ntoskrnl.
Oh … normally, depending on the chipset / CPU, the idle loop is
normally IntelPPM!ACPIC1Idle, or the equivalent in the AMD CPU driver…
MH.
Martin Harvey wrote:
Jakob Bohm wrote:
> It helped a lot, after I manually tracked down and eliminated the
> false hits on the CPU sleeping loop just after
> Exi386InterlockedExchangeUlong in ntoskrnl.
>
>
Oh … normally, depending on the chipset / CPU, the idle loop is
normally IntelPPM!ACPIC1Idle, or the equivalent in the AMD CPU driver…
On W2K SP4, there is no CPU driver, the code for each CPU is inside hal
and ntoskrnl and selected dynamically at boot time. The idle loop for
Xeon processors with HyperThreading enabled happens to have its hotspot
in the assembler code section just after the exported
Exi386InterlockedExchangeUlong function, causing kernrate to incorrectly
report that this hotspot is inside that function.
–
Jakob B?hm, M.Sc.Eng. * xxxxx@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right
Jakob Bohm wrote:
>
On W2K SP4, there is no CPU driver, the code for each CPU is inside
hal and ntoskrnl and selected dynamically at boot time. The idle loop
for Xeon processors with HyperThreading enabled happens to have its
hotspot in the assembler code section just after the exported
Exi386InterlockedExchangeUlong function, causing kernrate to
incorrectly report that this hotspot is inside that function.
Ah, OK. As a bit of a “heads up”, I should mention that I’ve seen
something similar in kernrate for Win2K3. If I remember correctly the
code in ntkrpa to deal with setting up and tearing down exception frames
is just before the “wctomb” function, but there are no symbols for them
that KernRate understands, hence some head-scratching on our part
thinking: “… but we’re not doing any conversion of wide chars to
multi-bytes!”
MH.