PHILIP:
Sorry I don’t have better to offer. I would agree that this problem
tends to be hard to predict/reproduce, so what I thought fixed this
problem for me very well may not have.
Best of luck,
mm
>> xxxxx@guillemot.com 2006-12-14 17:29 >>>
Hello, thanks for your reply.
I’ve tried deleting my symbol store, to no permanent effect (either the
issue returned, or it had no effect). Here is my symbol server path,
which is fine to my knowledge:
SRV*c:\windows\symbols*http://msdl.microsoft.com/download/symbols;
It’s also fairly intermittent, and I’ve never seen this using COM port
debugging. Then again, I didn’t have this version of WinDBG either.
I’ve tried older versions, with no seeming fundamental change.
thanks for your reply,
Philip Lukidis
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Martin
O’Brien
Sent: Thursday, December 14, 2006 1:27 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] 1394 debugging and near 100% CPU utilization
I can’t say that I know offhand, but, short of any easier
ideas, I would
try exiting WinDbg (with the symbol path intact), deleting your
entire
local symbol store (assuming you are using one; if not, this would
be
the place to start), starting WinDbg set to break in ASAP, and then
issuing a .reload -f -n. This might take a while, but I have
found that
this sometimes gets rid of this sort of problem. Another
possibility is
that your symbol path is malformed; that is, you have something like
“srv**C:\temphttp://,” or something else that causes the search
engine
to freak out rather just bail on non-existent directories.
mm
>>> xxxxx@guillemot.com 2006-12-14 09:29 >>>
Hello. Since I am trying to debug a Vista system with no COM port,
I
have no immediate recourse except to use firewire debugging (a USB
debugging cable is on the way). Although it works fine most of the
time, there are times when the CPU utilization on the host
(specifically
WinDBG itself) skyrockets to near 100%. This usually (but not
always)
happens during the boot sequence of the target, or when the target
BSODs. The last case is particularly bad, because it impedes BSOD
analysis.
I found a workaround, in when this happens, I close WinDBG, reopen
WinDBG, and I remove the symbol path to the system symbols (leaving
my
driver’s symbol path intact). Thereafter, after the boot sequence
or
BSOD analysis is complete, I restore the system symbol path, and
reanalyze if necessary. This seems to occur with or without
the use of
a symbol server (though this remains to be confirmed).
Does anyone have any idea what is going on? I’ve never seen
this using
a COM port. I’m using WinXP SP2 on the host, with WinDBG 6.6.0007.5
thanks for any help,
Philip Lukidis
You are currently subscribed to windbg as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com
You are currently subscribed to windbg as: xxxxx@guillemot.com
To unsubscribe send a blank email to
xxxxx@lists.osr.com
You are currently subscribed to windbg as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com