On and off from quite some time (over 2 years) I have been troubled by
windbg (running k-mode though a 1394) sitting chewing CPU and not doing much
visible (in other word it is not hitting the symbol server). Hitting ^C or
has no effect.
I cannot find any trend as to why it should happen. I don’t take notes but
I have a feeling that I usually get so frustrated that I wind back through
progressively older releases until I find one which doesn’t hang. Then I
forget why I’m running that version and some of the other bugs in the older
releases drives me to upgrade…
Is it worth spending some time poking at it with another windbg to find
where it’s looping? If I am not the only person to see this (and there has
to be something odd with my settings since ASSERTs are not firing for me -
http://www.osronline.com/cf.cfm?PageURL=showlists.CFM?list=WINDBG) what do
other people do when Windbg loops for them?
Rod
PS is it my imagination but does the latest version of Windbg keep on
putting http://msdl.microsoft.com/download/symbols back into your sympath
even if you don’t want it there because of the huge delays when it starts
looking for symbols that it isn’t going to find? Is there a way to tell it
not to?
> On and off from quite some time (over 2 years) I have been troubled by
windbg (running k-mode though a 1394) sitting chewing CPU and not doing
much visible (in other word it is not hitting the symbol server). Hitting
^C or has no effect.
Are you broken in when this happens or is the target running? Generally I
find that these things are symbol related, so you have an unqualified value
in your watch window or something (I’ve also had inconclusive evidence in
labs that this can happen if you end up with a corrupted PDB somehow,
deleting the cache works). Breaking in with another debugger could be
informative, a call stack might give some kind of clue.
> PS is it my imagination but does the latest version of Windbg keep on
> putting http://msdl.microsoft.com/download/symbols back into your sympath
> even if you don’t want it there because of the huge delays when it starts
> looking for symbols that it isn’t going to find? Is there a way to tell
> it not to?
Is it saved in your workspace? Or did you manage to set _NT_SYMBOL_PATH for
some reason at some point in time (it’s happened to me before :))?
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Rod Widdowson” wrote in message
news:xxxxx@windbg…
> On and off from quite some time (over 2 years) I have been troubled by
> windbg (running k-mode though a 1394) sitting chewing CPU and not doing
> much visible (in other word it is not hitting the symbol server). Hitting
> ^C or has no effect.
>
> I cannot find any trend as to why it should happen. I don’t take notes
> but I have a feeling that I usually get so frustrated that I wind back
> through progressively older releases until I find one which doesn’t hang.
> Then I forget why I’m running that version and some of the other bugs in
> the older releases drives me to upgrade…
>
> Is it worth spending some time poking at it with another windbg to find
> where it’s looping? If I am not the only person to see this (and there
> has to be something odd with my settings since ASSERTs are not firing for
> me - http://www.osronline.com/cf.cfm?PageURL=showlists.CFM?list=WINDBG)
> what do other people do when Windbg loops for them?
>
> Rod
>
> PS is it my imagination but does the latest version of Windbg keep on
> putting http://msdl.microsoft.com/download/symbols back into your sympath
> even if you don’t want it there because of the huge delays when it starts
> looking for symbols that it isn’t going to find? Is there a way to tell
> it not to?
>
Re: msdl.microsoft.com, try clearing your image path with “.exepath”.
- S
-----Original Message-----
From: Scott Noone
Sent: Tuesday, December 22, 2009 6:48
To: Kernel Debugging Interest List
Subject: Re:[windbg] WinDbg pegging the CPU…
> On and off from quite some time (over 2 years) I have been troubled by
> windbg (running k-mode though a 1394) sitting chewing CPU and not doing
> much visible (in other word it is not hitting the symbol server). Hitting
> ^C or has no effect.
Are you broken in when this happens or is the target running? Generally I
find that these things are symbol related, so you have an unqualified value
in your watch window or something (I’ve also had inconclusive evidence in
labs that this can happen if you end up with a corrupted PDB somehow,
deleting the cache works). Breaking in with another debugger could be
informative, a call stack might give some kind of clue.
> PS is it my imagination but does the latest version of Windbg keep on
> putting http://msdl.microsoft.com/download/symbols back into your sympath
> even if you don’t want it there because of the huge delays when it starts
> looking for symbols that it isn’t going to find? Is there a way to tell
> it not to?
Is it saved in your workspace? Or did you manage to set _NT_SYMBOL_PATH for
some reason at some point in time (it’s happened to me before :))?
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Rod Widdowson” wrote in message
news:xxxxx@windbg…
> On and off from quite some time (over 2 years) I have been troubled by
> windbg (running k-mode though a 1394) sitting chewing CPU and not doing
> much visible (in other word it is not hitting the symbol server). Hitting
> ^C or has no effect.
>
> I cannot find any trend as to why it should happen. I don’t take notes
> but I have a feeling that I usually get so frustrated that I wind back
> through progressively older releases until I find one which doesn’t hang.
> Then I forget why I’m running that version and some of the other bugs in
> the older releases drives me to upgrade…
>
> Is it worth spending some time poking at it with another windbg to find
> where it’s looping? If I am not the only person to see this (and there
> has to be something odd with my settings since ASSERTs are not firing for
> me - http://www.osronline.com/cf.cfm?PageURL=showlists.CFM?list=WINDBG)
> what do other people do when Windbg loops for them?
>
> Rod
>
> PS is it my imagination but does the latest version of Windbg keep on
> putting http://msdl.microsoft.com/download/symbols back into your sympath
> even if you don’t want it there because of the huge delays when it starts
> looking for symbols that it isn’t going to find? Is there a way to tell
> it not to?
>
—
WINDBG is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> Are you broken in when this happens or is the target running?
Its usually broken (30 minutes waiting for !analyze -v)
Generally I find that these things are symbol related,
Often yes, but not this time…
Breaking in with another debugger could be informative, a call stack might
give some kind of clue.
Hmm, maybe a noisy 1394 cable - this seems to be sucking the time…
ntdll!ZwWriteFile
kernel32!WriteFile
dbgeng!Kd1394Connection::Write
dbgeng!KdConnection::WriteAll
dbgeng!Kd1394Connection::WritePacketContents
dbgeng!DbgKdTransport::WritePacketContents
dbgeng!DbgKdTransport::WriteDataPacket
dbgeng!DbgKdTransport::WritePacket
dbgeng!DbgKdTransport::SendReceivePacket
dbgeng!DbgKdTransport::SendReceiveManip
dbgeng!ConnLiveKernelTargetInfo::ReadControl
dbgeng!MachineInfo::ReadProcessorSystemDataOffset
dbgeng!TargetInfo::GetProcessorSystemDataOffset
dbgeng!DebugClient::ReadProcessorSystemData
ext!GetCurrentIrql
ext!BcFillAnalysis
ext!BcAnalyze
ext!AnalyzeBugCheck
ext!analyze
dbgeng!ExtensionInfo::CallA
dbgeng!ExtensionInfo::Call
dbgeng!ExtensionInfo::CallAny
dbgeng!ParseBangCmd
dbgeng!ProcessCommands
dbgeng!ProcessCommandsAndCatch
dbgeng!Execute
dbgeng!DebugClient::ExecuteWide
windbg!ProcessCommand
windbg!ProcessEngineCommands
windbg!EngineLoop
kernel32!BaseThreadInitThunk
ntdll!RtlUserThreadStart
And before people mention it, yes this is a target with a TI chipset - as I
mentioned this is actually OK with some versions of windbg and so the
variant is that, not the hardware. My impression is that the 64 bit windbg
is slightly worse than the 32 bit one…
I’ll get new cables and see what happens and report back.
R