Just to keep the thread alive. I am now getting this behavior on a KDVM connection & dumps – so it isn’t a 1394 thing. I know that it isn’t a symbol server issue. I am wondering whether it is a 64 bit target issue?
From previous messages I have to assume that I am the only one seeing behavior. Might it be worthwhile doing a reinstall of the debugger?
/R
“Rod Widdowson” wrote in message news:xxxxx@windbg…
(For completeness).
And suddenly it is fast again with no change to configuration.
Thanks for the input, I’ll keep all these posts against the next time things go wrong…
Rod
“Rod Widdowson” wrote in message news:xxxxx@windbg…
This bites me every 3 months or so.
It can take between 5 and 30 minutes to return to the Windbg> prompt (particularly after a crash)
- My symbol path is entirely local (cache*;g:\path)
- Debugging (CTRL/ALT-V shows no traffic)
- Debug->Resolve unqualified symbols: unticked.
Last time this happened I just gave up and used VMs (which can be less than satisfactory, byt kdvm is pretty cool). Then I bought a new external 1394 and things became much better. Suddenly last night things started being dead slow again.
This does not happen using KDVM debugging with everything else (for instance the symbol cache) being the same.
Any suggestions would be more than welcome.
A couple of busy stacks are show below.
dbghelp!DBI1::fReadSymRec
dbghelp!GSI1::NextSym
dbghelp!CAllPubNameTrav::next
dbghelp!CDiaEnumTraversal >::Next
dbghelp!diaGetGlobals
dbghelp!diaGetSymbols
dbghelp!diaEnumSymbols
dbghelp!modEnumSymbols
dbghelp!ModLoop
dbghelp!EnumSymbols
dbghelp!SymEnumSymbolsW
dbgeng!EnumSymbolInfoRaw
dbgeng!GetOffsetFromSym
dbgeng!GetSimpleSymOffset
dbgeng!TargetInfo::GetUnloadedModuleMemoryInfo
dbgeng!NtUserUnloadedModuleInfo::Initialize
dbgeng!ProcessInfo::AddUnloadedImages
dbgeng!ProcessInfo::AddAllTargetUnloadedImages
dbgeng!ProcModIter::Start
dbgeng!DebugClient::GetModuleNames
ext!DebugFailureAnalysis::BuildModuleAliases
ext!BcFillAnalysis
ext!BcAnalyze
ext!AnalyzeBugCheck
ext!analyze
dbgeng!ExtensionInfo::CallA
dbgeng!ExtensionInfo::Call
dbgeng!ExtensionInfo::CallAny
dbgeng!CallBugCheckExtension
dbgeng!HandleBPWithStatus
dbgeng!PrepareForCalls
dbgeng!RawWaitForEvent
dbgeng!DebugClient::WaitForEvent
windbg!EngineLoop
kernel32!BaseThreadInitThunk
ntdll!RtlUserThreadStart
msvcrt!DName::operator+=
msvcrt!DName::operator+
msvcrt!UnDecorator::getScope
msvcrt!UnDecorator::getDecoratedName
msvcrt!UnDecorator::operator char * __ptr64
msvcrt!_unDName
dbghelp!UndecorateWrapper::match
dbghelp!CAllPubNameTrav::next
dbghelp!CDiaEnumTraversal >::Next
dbghelp!diaGetGlobals
dbghelp!diaGetSymbols
dbghelp!diaEnumSymbols
dbghelp!modEnumSymbols
dbghelp!ModLoop
dbghelp!EnumSymbols
dbghelp!SymEnumSymbolsW
dbgeng!FindTypeInfoInMod
dbgeng!TypeInfoFound
dbgeng!TypedData::FindType
dbgeng!CppEvalExpression::CollectTypeOrSymbolName
dbgeng!CppEvalExpression::Term
dbgeng!CppEvalExpression::Postfix
dbgeng!CppEvalExpression::Unary
dbgeng!CppEvalExpression::Cast
dbgeng!CppEvalExpression::ClassMemberRef
dbgeng!CppEvalExpression::Multiplicative
dbgeng!CppEvalExpression::Additive
dbgeng!CppEvalExpression::Shift
dbgeng!CppEvalExpression::Relational
dbgeng!CppEvalExpression::Equality
dbgeng!CppEvalExpression::BitwiseAnd
dbgeng!CppEvalExpression::BitwiseXor
dbgeng!CppEvalExpression::BitwiseOr
dbgeng!CppEvalExpression::LogicalAnd
dbgeng!CppEvalExpression::LogicalOr
dbgeng!CppEvalExpression::Conditional
dbgeng!CppEvalExpression::Assignment
dbgeng!CppEvalExpression::Expression
dbgeng!CppEvalExpression::Evaluate
dbgeng!EvalExpression::EvalCurrent
dbgeng!EvalCurrentAndOutput
dbgeng!EvaluateTypedExpr
dbgeng!ProcessCommands
dbgeng!ProcessCommandsAndCatch
dbgeng!Execute
dbgeng!DebugClient::ExecuteWide
windbg!EvalToStateBuffer::ReadState
windbg!StateBuffer::Update
windbg!EvalToBuffer
windbg!ProcessCommand
windbg!ProcessEngineCommands
windbg!EngineLoop
kernel32!BaseThreadInitThunk
ntdll!RtlUserThreadStart
Reinstalling the debuggers is not likely to change anything earthshattering as the debuggers maintain very little persisted install state. Running without workspaces in use (windbg -WX or use a console debugger) is going to give you the same result.
Can you debug the debugger when it’s doing this and get a stack trace of what happened this time?
Additionally, I believe we shipped an updated WinDbg distribution with the Windows Developer Preview release (which included a new WDK preinstalled). That build should include a fix for at least one issue that may result in the debugger spinning its wheels for a long time needlessly in dbgeng!ProcessInfo::AddAllTargetUnloadedImages (if certain parts of user mode memory were inaccessible when bringing up a KD session). You may want to try and give that updated build a shot and see if it resolves this for you.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Rod Widdowson
Sent: Sunday, November 13, 2011 6:46 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Redux: Windbg/1394 as slow as a aged dog on barbiturates.
Just to keep the thread alive. I am now getting this behavior on a KDVM connection & dumps - so it isn’t a 1394 thing. I know that it isn’t a symbol server issue. I am wondering whether it is a 64 bit target issue?
From previous messages I have to assume that I am the only one seeing behavior. Might it be worthwhile doing a reinstall of the debugger?
/R
“Rod Widdowson” > wrote in message news:xxxxx@windbg…
(For completeness).
And suddenly it is fast again with no change to configuration.
Thanks for the input, I’ll keep all these posts against the next time things go wrong…
Rod
“Rod Widdowson” > wrote in message news:xxxxx@windbg…
This bites me every 3 months or so.
It can take between 5 and 30 minutes to return to the Windbg> prompt (particularly after a crash)
- My symbol path is entirely local (cache*;g:\path)
- Debugging (CTRL/ALT-V shows no traffic)
- Debug->Resolve unqualified symbols: unticked.
Last time this happened I just gave up and used VMs (which can be less than satisfactory, byt kdvm is pretty cool). Then I bought a new external 1394 and things became much better. Suddenly last night things started being dead slow again.
This does not happen using KDVM debugging with everything else (for instance the symbol cache) being the same.
Any suggestions would be more than welcome.
A couple of busy stacks are show below.
dbghelp!DBI1::fReadSymRec
dbghelp!GSI1::NextSym
dbghelp!CAllPubNameTrav::next
dbghelp!CDiaEnumTraversal >::Next
dbghelp!diaGetGlobals
dbghelp!diaGetSymbols
dbghelp!diaEnumSymbols
dbghelp!modEnumSymbols
dbghelp!ModLoop
dbghelp!EnumSymbols
dbghelp!SymEnumSymbolsW
dbgeng!EnumSymbolInfoRaw
dbgeng!GetOffsetFromSym
dbgeng!GetSimpleSymOffset
dbgeng!TargetInfo::GetUnloadedModuleMemoryInfo
dbgeng!NtUserUnloadedModuleInfo::Initialize
dbgeng!ProcessInfo::AddUnloadedImages
dbgeng!ProcessInfo::AddAllTargetUnloadedImages
dbgeng!ProcModIter::Start
dbgeng!DebugClient::GetModuleNames
ext!DebugFailureAnalysis::BuildModuleAliases
ext!BcFillAnalysis
ext!BcAnalyze
ext!AnalyzeBugCheck
ext!analyze
dbgeng!ExtensionInfo::CallA
dbgeng!ExtensionInfo::Call
dbgeng!ExtensionInfo::CallAny
dbgeng!CallBugCheckExtension
dbgeng!HandleBPWithStatus
dbgeng!PrepareForCalls
dbgeng!RawWaitForEvent
dbgeng!DebugClient::WaitForEvent
windbg!EngineLoop
kernel32!BaseThreadInitThunk
ntdll!RtlUserThreadStart
msvcrt!DName::operator+=
msvcrt!DName::operator+
msvcrt!UnDecorator::getScope
msvcrt!UnDecorator::getDecoratedName
msvcrt!UnDecorator::operator char * __ptr64
msvcrt!_unDName
dbghelp!UndecorateWrapper::match
dbghelp!CAllPubNameTrav::next
dbghelp!CDiaEnumTraversal >::Next
dbghelp!diaGetGlobals
dbghelp!diaGetSymbols
dbghelp!diaEnumSymbols
dbghelp!modEnumSymbols
dbghelp!ModLoop
dbghelp!EnumSymbols
dbghelp!SymEnumSymbolsW
dbgeng!FindTypeInfoInMod
dbgeng!TypeInfoFound
dbgeng!TypedData::FindType
dbgeng!CppEvalExpression::CollectTypeOrSymbolName
dbgeng!CppEvalExpression::Term
dbgeng!CppEvalExpression::Postfix
dbgeng!CppEvalExpression::Unary
dbgeng!CppEvalExpression::Cast
dbgeng!CppEvalExpression::ClassMemberRef
dbgeng!CppEvalExpression::Multiplicative
dbgeng!CppEvalExpression::Additive
dbgeng!CppEvalExpression::Shift
dbgeng!CppEvalExpression::Relational
dbgeng!CppEvalExpression::Equality
dbgeng!CppEvalExpression::BitwiseAnd
dbgeng!CppEvalExpression::BitwiseXor
dbgeng!CppEvalExpression::BitwiseOr
dbgeng!CppEvalExpression::LogicalAnd
dbgeng!CppEvalExpression::LogicalOr
dbgeng!CppEvalExpression::Conditional
dbgeng!CppEvalExpression::Assignment
dbgeng!CppEvalExpression::Expression
dbgeng!CppEvalExpression::Evaluate
dbgeng!EvalExpression::EvalCurrent
dbgeng!EvalCurrentAndOutput
dbgeng!EvaluateTypedExpr
dbgeng!ProcessCommands
dbgeng!ProcessCommandsAndCatch
dbgeng!Execute
dbgeng!DebugClient::ExecuteWide
windbg!EvalToStateBuffer::ReadState
windbg!StateBuffer::Update
windbg!EvalToBuffer
windbg!ProcessCommand
windbg!ProcessEngineCommands
windbg!EngineLoop
kernel32!BaseThreadInitThunk
ntdll!RtlUserThreadStart
—
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
> Reinstalling the debuggers is not likely to change anything earthshattering as the debuggers maintain very little persisted install state
That was my experience (although I had to do an admin install to get it to install where I wanted it), but thanks
Additionally, I believe we shipped an updated WinDbg distribution with the Windows
Developer Preview release (which included a new WDK preinstalled). That build should
include a fix for at least one issue that may result in the debugger spinning its wheels for
a long time needlessly in dbgeng!ProcessInfo::AddAllTargetUnloadedImages (
Certainly that call is on the stacks I gathered back in august…
I’ll fire up the developer prerelease and see what I can see.
Thanks
“Skywing” wrote in message news:xxxxx@windbg…
Reinstalling the debuggers is not likely to change anything earthshattering as the debuggers maintain very little persisted install state. Running without workspaces in use (windbg -WX or use a console debugger) is going to give you the same result.
Can you debug the debugger when it’s doing this and get a stack trace of what happened this time?
Additionally, I believe we shipped an updated WinDbg distribution with the Windows Developer Preview release (which included a new WDK preinstalled). That build should include a fix for at least one issue that may result in the debugger spinning its wheels for a long time needlessly in dbgeng!ProcessInfo::AddAllTargetUnloadedImages (if certain parts of user mode memory were inaccessible when bringing up a KD session). You may want to try and give that updated build a shot and see if it resolves this for you.
- S (Msft)
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Rod Widdowson
Sent: Sunday, November 13, 2011 6:46 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Redux: Windbg/1394 as slow as a aged dog on barbiturates.
Just to keep the thread alive. I am now getting this behavior on a KDVM connection & dumps – so it isn’t a 1394 thing. I know that it isn’t a symbol server issue. I am wondering whether it is a 64 bit target issue?
From previous messages I have to assume that I am the only one seeing behavior. Might it be worthwhile doing a reinstall of the debugger?
/R
“Rod Widdowson” wrote in message news:xxxxx@windbg…
(For completeness).
And suddenly it is fast again with no change to configuration.
Thanks for the input, I’ll keep all these posts against the next time things go wrong…
Rod
“Rod Widdowson” wrote in message news:xxxxx@windbg…
This bites me every 3 months or so.
It can take between 5 and 30 minutes to return to the Windbg> prompt (particularly after a crash)
- My symbol path is entirely local (cache*;g:\path)
- Debugging (CTRL/ALT-V shows no traffic)
- Debug->Resolve unqualified symbols: unticked.
Last time this happened I just gave up and used VMs (which can be less than satisfactory, byt kdvm is pretty cool). Then I bought a new external 1394 and things became much better. Suddenly last night things started being dead slow again.
This does not happen using KDVM debugging with everything else (for instance the symbol cache) being the same.
Any suggestions would be more than welcome.
A couple of busy stacks are show below.
dbghelp!DBI1::fReadSymRec
dbghelp!GSI1::NextSym
dbghelp!CAllPubNameTrav::next
dbghelp!CDiaEnumTraversal >::Next
dbghelp!diaGetGlobals
dbghelp!diaGetSymbols
dbghelp!diaEnumSymbols
dbghelp!modEnumSymbols
dbghelp!ModLoop
dbghelp!EnumSymbols
dbghelp!SymEnumSymbolsW
dbgeng!EnumSymbolInfoRaw
dbgeng!GetOffsetFromSym
dbgeng!GetSimpleSymOffset
dbgeng!TargetInfo::GetUnloadedModuleMemoryInfo
dbgeng!NtUserUnloadedModuleInfo::Initialize
dbgeng!ProcessInfo::AddUnloadedImages
dbgeng!ProcessInfo::AddAllTargetUnloadedImages
dbgeng!ProcModIter::Start
dbgeng!DebugClient::GetModuleNames
ext!DebugFailureAnalysis::BuildModuleAliases
ext!BcFillAnalysis
ext!BcAnalyze
ext!AnalyzeBugCheck
ext!analyze
dbgeng!ExtensionInfo::CallA
dbgeng!ExtensionInfo::Call
dbgeng!ExtensionInfo::CallAny
dbgeng!CallBugCheckExtension
dbgeng!HandleBPWithStatus
dbgeng!PrepareForCalls
dbgeng!RawWaitForEvent
dbgeng!DebugClient::WaitForEvent
windbg!EngineLoop
kernel32!BaseThreadInitThunk
ntdll!RtlUserThreadStart
msvcrt!DName::operator+=
msvcrt!DName::operator+
msvcrt!UnDecorator::getScope
msvcrt!UnDecorator::getDecoratedName
msvcrt!UnDecorator::operator char * __ptr64
msvcrt!_unDName
dbghelp!UndecorateWrapper::match
dbghelp!CAllPubNameTrav::next
dbghelp!CDiaEnumTraversal >::Next
dbghelp!diaGetGlobals
dbghelp!diaGetSymbols
dbghelp!diaEnumSymbols
dbghelp!modEnumSymbols
dbghelp!ModLoop
dbghelp!EnumSymbols
dbghelp!SymEnumSymbolsW
dbgeng!FindTypeInfoInMod
dbgeng!TypeInfoFound
dbgeng!TypedData::FindType
dbgeng!CppEvalExpression::CollectTypeOrSymbolName
dbgeng!CppEvalExpression::Term
dbgeng!CppEvalExpression::Postfix
dbgeng!CppEvalExpression::Unary
dbgeng!CppEvalExpression::Cast
dbgeng!CppEvalExpression::ClassMemberRef
dbgeng!CppEvalExpression::Multiplicative
dbgeng!CppEvalExpression::Additive
dbgeng!CppEvalExpression::Shift
dbgeng!CppEvalExpression::Relational
dbgeng!CppEvalExpression::Equality
dbgeng!CppEvalExpression::BitwiseAnd
dbgeng!CppEvalExpression::BitwiseXor
dbgeng!CppEvalExpression::BitwiseOr
dbgeng!CppEvalExpression::LogicalAnd
dbgeng!CppEvalExpression::LogicalOr
dbgeng!CppEvalExpression::Conditional
dbgeng!CppEvalExpression::Assignment
dbgeng!CppEvalExpression::Expression
dbgeng!CppEvalExpression::Evaluate
dbgeng!EvalExpression::EvalCurrent
dbgeng!EvalCurrentAndOutput
dbgeng!EvaluateTypedExpr
dbgeng!ProcessCommands
dbgeng!ProcessCommandsAndCatch
dbgeng!Execute
dbgeng!DebugClient::ExecuteWide
windbg!EvalToStateBuffer::ReadState
windbg!StateBuffer::Update
windbg!EvalToBuffer
windbg!ProcessCommand
windbg!ProcessEngineCommands
windbg!EngineLoop
kernel32!BaseThreadInitThunk
ntdll!RtlUserThreadStart
—
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
Early indications are that this is precisely what has been biting me. Thank you so much for this fix.
And thanks for making it possible to run that release downrev…
Additionally, I believe we shipped an updated WinDbg distribution with the Windows Developer Preview release (which included a new WDK preinstalled). That build should include a fix for at least one issue that may result in the debugger spinning its wheels for a long time needlessly in dbgeng!ProcessInfo::AddAllTargetUnloadedImages (if certain parts of user mode memory were inaccessible when bringing up a KD session). You may want to try and give that updated build a shot and see if it resolves this for you.