Extremely slow kernel debugging in Windbg

[Eric Dacquay]

I've always had trouble getting Windbg to connect properly to do kernel
debugging. Today however not only am I having difficulty connecting, but
when it does connect it is ludicrously slow. About 10 minutes after having
started the machine, this was all that was being displayed:

Using 1394 for debugging
Opened \\.\DBG1394_INSTANCE01
Waiting to reconnect...
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is:
c:\windows\symbols;SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 UP Free x86 compatible
Built by: 2600.xpsp_sp2_gdr.050301-1519
Kernel base = 0x80800000 PsLoadedModuleList = 0x8087c1a0
System Uptime: not available

At this point I decided to hit CTRL+BREAK and it brought up the debugger but
it has been loading kernel symbols for the past 20 minutes yet all that is
being show in terms of progress is

Loading Kernel Symbols
.....

I am using a 1394 conection and my host computer is running XP SP2. I have
tried to run the host with and without manually disabling the 1394 Host
Controller. Either way I get the same behavior. I also tried both versions
6.5.3.7 and 6.4.7.2. Again, I see no difference between the two. While I
wait, my monitor on my target computer is blank and the bootup screen with
the Windows XP logo hasn't come up yet.

Any ideas as to what I could do to get this working properly would be
greatly appreciated.

Thanks

Eric

[Jason Shay [MSFT]]

If you type ctrl+d<enter> in kd, you should get spew. What's it look like?
Errors? If so, check cables. Even try swapping 1394 cards if you've got a
few, as I've seen hardware issues cause bad connections before.
--
Jason Shay [MSFT]
***@online.microsoft.com

This posting is provided "AS IS" with no warranties, and confers no rights
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Post by Eric Dacquay
I've always had trouble getting Windbg to connect properly to do kernel
debugging. Today however not only am I having difficulty connecting, but
when it does connect it is ludicrously slow. About 10 minutes after having
Using 1394 for debugging
Opened \\.\DBG1394_INSTANCE01
Waiting to reconnect...
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Kernel Debugger connection established.
c:\windows\symbols;SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Windows XP Kernel Version 2600 UP Free x86 compatible
Built by: 2600.xpsp_sp2_gdr.050301-1519
Kernel base = 0x80800000 PsLoadedModuleList = 0x8087c1a0
System Uptime: not available
At this point I decided to hit CTRL+BREAK and it brought up the debugger but
it has been loading kernel symbols for the past 20 minutes yet all that is
being show in terms of progress is
Loading Kernel Symbols
.....
I am using a 1394 conection and my host computer is running XP SP2. I have
tried to run the host with and without manually disabling the 1394 Host
Controller. Either way I get the same behavior. I also tried both versions
6.5.3.7 and 6.4.7.2. Again, I see no difference between the two. While I
wait, my monitor on my target computer is blank and the bootup screen with
the Windows XP logo hasn't come up yet.
Any ideas as to what I could do to get this working properly would be
greatly appreciated.
Thanks
Eric

[Eric Dacquay]

I was getting an error almost continuously. I played around with the cable,
tried different ports on my 2 firewire cards and things seem to be much
better now. If I look at the output in kd though, I will still occasionaly
get the following error:

READ: Error 80070014

Can I safely ignore this or is there anything I can do about it?

Thanks for the help

Eric

Post by Jason Shay [MSFT]
If you type ctrl+d<enter> in kd, you should get spew. What's it look like?
Errors? If so, check cables. Even try swapping 1394 cards if you've got a
few, as I've seen hardware issues cause bad connections before.

[Jason Shay [MSFT]]

That's the error I usually see. Every once in a while should be okay. But
when I see slowdowns or complete loss of traffic, its because of that error.
And in most cases I've seen, swapping hardware/cables is how to fix it
permanently.
--
Jason Shay [MSFT]
***@online.microsoft.com

This posting is provided "AS IS" with no warranties, and confers no rights
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Post by Eric Dacquay
I was getting an error almost continuously. I played around with the cable,
tried different ports on my 2 firewire cards and things seem to be much
better now. If I look at the output in kd though, I will still occasionaly
READ: Error 80070014
Can I safely ignore this or is there anything I can do about it?
Thanks for the help
Eric

Post by Jason Shay [MSFT]
If you type ctrl+d<enter> in kd, you should get spew. What's it look like?
Errors? If so, check cables. Even try swapping 1394 cards if you've got a
few, as I've seen hardware issues cause bad connections before.

[poly]

I am happy for using COM port.

Post by Eric Dacquay
I've always had trouble getting Windbg to connect properly to do kernel
debugging. Today however not only am I having difficulty connecting, but
when it does connect it is ludicrously slow. About 10 minutes after having
Using 1394 for debugging
Opened \\.\DBG1394_INSTANCE01
Waiting to reconnect...
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Kernel Debugger connection established.
c:\windows\symbols;SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Windows XP Kernel Version 2600 UP Free x86 compatible
Built by: 2600.xpsp_sp2_gdr.050301-1519
Kernel base = 0x80800000 PsLoadedModuleList = 0x8087c1a0
System Uptime: not available
At this point I decided to hit CTRL+BREAK and it brought up the debugger but
it has been loading kernel symbols for the past 20 minutes yet all that is
being show in terms of progress is
Loading Kernel Symbols
.....
I am using a 1394 conection and my host computer is running XP SP2. I have
tried to run the host with and without manually disabling the 1394 Host
Controller. Either way I get the same behavior. I also tried both versions
6.5.3.7 and 6.4.7.2. Again, I see no difference between the two. While I
wait, my monitor on my target computer is blank and the bootup screen with
the Windows XP logo hasn't come up yet.
Any ideas as to what I could do to get this working properly would be
greatly appreciated.
Thanks
Eric

[Alan Adams]

I have tried to run the host with and without manually disabling
the 1394 Host Controller.

Maybe it's already what you meant, but disabling the 1394 Host
Controller is something you do on the target machine, not the host
where you run WinDBG. At least that's how the "Disabling the 1394
Host Controller" section reads for me. Maybe that figures into why
its tough to get a connection at all; not sure.

...when it does connect it is ludicrously slow. ...While I
wait, my monitor on my target computer is blank and the bootup
screen with the Windows XP logo hasn't come up yet.

I tend to get that kind of slowness if I start WinDBG and start the
"Kernel Debug" -> "1394" connection first, and then only afterwards
start the target machine in /DEBUG mode. (i.e. WinDBG has started
"listening" before the host OS ever starts booting up.) This seems to
result in a deadly slow connection; unusable.

Someone once posted a tip here suggesting not to attempt connecting to
the target machine until after you had the target machine up and
logged in to the desktop. And I have found that approach to work for
me consistently, too.

i.e. Start the target OS in /DEBUG mode, but don't start WinDBG and/or
the "Kernel Debug" -> "1394" connection menu option until the target
machine is "ready" and logged in. Then start the WinDBG's kernel
debugger connection and manually break in to force the kernel debug
connection to be established.

Now that you have a successful (and fast) 1394 debugger connection,
reboot the target machine to your hearts content (if what you actually
needed was to debug a boot-time issue or whatever). Even though the
connection will be disconnected & reconnected every time you reboot
the target, something about getting the initial connection established
in this manner keeps the "slow connection" from happening, at least in
my case.

(Yep; have 1394 controller disabled in target's Device Manager, happen
to also have 1384 net adapter disabled on WinDBG host machine. The
1394 cable would appear to be fine because the connection, once fast,
works great and for as long as I leave WinDBG open. Just something
about how that initial connection or "sync" is done that seems to
"make or break" whether the connection will be slow instead of fast
for the entire session of however long you run WinDBG.)

It's been easy enough to deal with I haven't tried to figure out
anything better; if someone is aware of what's causing this type of
behavior, it would be great to know.

I've always had trouble getting Windbg to connect properly to do kernel
debugging. Today however not only am I having difficulty connecting, but
when it does connect it is ludicrously slow. About 10 minutes after having
Using 1394 for debugging
Opened \\.\DBG1394_INSTANCE01
Waiting to reconnect...
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
Kernel Debugger connection established.
c:\windows\symbols;SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Windows XP Kernel Version 2600 UP Free x86 compatible
Built by: 2600.xpsp_sp2_gdr.050301-1519
Kernel base = 0x80800000 PsLoadedModuleList = 0x8087c1a0
System Uptime: not available
At this point I decided to hit CTRL+BREAK and it brought up the debugger but
it has been loading kernel symbols for the past 20 minutes yet all that is
being show in terms of progress is
Loading Kernel Symbols
.....
I am using a 1394 conection and my host computer is running XP SP2. I have
tried to run the host with and without manually disabling the 1394 Host
Controller. Either way I get the same behavior. I also tried both versions
6.5.3.7 and 6.4.7.2. Again, I see no difference between the two. While I
wait, my monitor on my target computer is blank and the bootup screen with
the Windows XP logo hasn't come up yet.
Any ideas as to what I could do to get this working properly would be
greatly appreciated.
Thanks
Eric

Alan Adams
***@drcrumb.com
(to email, remove the crumbs)

[Eric Dacquay]

Post by Alan Adams

I have tried to run the host with and without manually disabling
the 1394 Host Controller.

Maybe it's already what you meant, but disabling the 1394 Host
Controller is something you do on the target machine, not the host
where you run WinDBG. At least that's how the "Disabling the 1394
Host Controller" section reads for me. Maybe that figures into why
its tough to get a connection at all; not sure.

Yes, I was refering to the target machine, upon re-reading I see I could
have been a bit clearer. Anyways, I finally managed to get it working by
playing around with the cable and trying different ports.

Post by Alan Adams
I tend to get that kind of slowness if I start WinDBG and start the
"Kernel Debug" -> "1394" connection first, and then only afterwards
start the target machine in /DEBUG mode. (i.e. WinDBG has started
"listening" before the host OS ever starts booting up.) This seems to
result in a deadly slow connection; unusable.
Someone once posted a tip here suggesting not to attempt connecting to
the target machine until after you had the target machine up and
logged in to the desktop. And I have found that approach to work for
me consistently, too.
i.e. Start the target OS in /DEBUG mode, but don't start WinDBG and/or
the "Kernel Debug" -> "1394" connection menu option until the target
machine is "ready" and logged in. Then start the WinDBG's kernel
debugger connection and manually break in to force the kernel debug
connection to be established.

Fortunately I don't have that problem. However, thanks for the information,
it might come in handy.

Eric