Target machine hangs without breaking into debugger

Hi,

I’m having trouble using windbg (and even just kd) to debug a driver that
I’ve written.

If I don’t have windbg or kd running on my host, I can open a handle to my
driver, and it can send bulk usb read requests down the usb stack and
complete them without problems.

However, if I have windbg or kd running and have managed to break into the
debugger and load symbols etc (but haven’t set any breakpoints), then I can
open a handle to my driver, but as soon as the completion routine runs for a
bulk usb read, the target freezes and windbg (and kd) fails to break into
the debugger. I know it’s stuck in the completion routine, because of the
debug output statements I see. My only recourse at that point is to
physically reset the target, and I don’t get to see the information I’m
interested in.

I’ve gotten about as far as I can debugging this driver using DbgPrint
statements and would like to actually use windbg (or even kd).

Any suggestions as to how I can get this working would be greatly
appreciated.

Thanks,
Linda

I could be stating the obvious here, but have you enabled driver
verifier on your driver, and any stacks that your driver is attached to
(e.g. usb)?

It’s possible that the driver verifier might catch a failure before it
takes out the system (assuming that your driver is taking out the
system).

Also using checked builds of the kernel / corresponding stacks may also
provide additional hints of what’s going wrong. Likewise testing on a
newer o/s release (assuming that you’re testing on an older o/s release
like W2K) might also expose the problem.

Or it could be something that has to do with the debugger. Make sure
you’re using the latest windbg/kd. And if you’re running over serial
try a slower baud rate. If you’re running over 1394, try disabling the
1394 port on the target system.

–Sandy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Linda Marcellus
Sent: Thursday, July 24, 2003 1:09 PM
To: Kernel Debugging Interest List
Subject: [windbg] Target machine hangs without breaking into debugger

Hi,

I’m having trouble using windbg (and even just kd) to debug a driver
that
I’ve written.

If I don’t have windbg or kd running on my host, I can open a handle to
my
driver, and it can send bulk usb read requests down the usb stack and
complete them without problems.

However, if I have windbg or kd running and have managed to break into
the
debugger and load symbols etc (but haven’t set any breakpoints), then I
can
open a handle to my driver, but as soon as the completion routine runs
for a
bulk usb read, the target freezes and windbg (and kd) fails to break
into
the debugger. I know it’s stuck in the completion routine, because of
the
debug output statements I see. My only recourse at that point is to
physically reset the target, and I don’t get to see the information I’m
interested in.

I’ve gotten about as far as I can debugging this driver using DbgPrint
statements and would like to actually use windbg (or even kd).

Any suggestions as to how I can get this working would be greatly
appreciated.

Thanks,
Linda


You are currently subscribed to windbg as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

This is why you always need a competitor. I use softice when windbg does
not help, and the other way round.

-Srin.

-----Original Message-----
From: Linda Marcellus [mailto:xxxxx@novatel.ca]
Sent: Thursday, July 24, 2003 1:09 PM
To: Kernel Debugging Interest List
Subject: [windbg] Target machine hangs without breaking into debugger

Hi,

I’m having trouble using windbg (and even just kd) to debug a driver
that
I’ve written.

If I don’t have windbg or kd running on my host, I can open a handle
to my
driver, and it can send bulk usb read requests down the usb stack and
complete them without problems.

However, if I have windbg or kd running and have managed to break into
the
debugger and load symbols etc (but haven’t set any breakpoints), then
I
can
open a handle to my driver, but as soon as the completion routine runs
for
a
bulk usb read, the target freezes and windbg (and kd) fails to break
into
the debugger. I know it’s stuck in the completion routine, because of
the
debug output statements I see. My only recourse at that point is to
physically reset the target, and I don’t get to see the information
I’m
interested in.

I’ve gotten about as far as I can debugging this driver using DbgPrint
statements and would like to actually use windbg (or even kd).

Any suggestions as to how I can get this working would be greatly
appreciated.

Thanks,
Linda


You are currently subscribed to windbg as: xxxxx@nai.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

“Linda Marcellus” wrote in message
news:xxxxx@windbg…
>
> Hi,
>
> I’m having trouble using windbg (and even just kd) to debug a driver that
> I’ve written.
>
> If I don’t have windbg or kd running on my host, I can open a handle to my
> driver, and it can send bulk usb read requests down the usb stack and
> complete them without problems.
>
> However, if I have windbg or kd running and have managed to break into the
> debugger and load symbols etc (but haven’t set any breakpoints), then I
can
> open a handle to my driver, but as soon as the completion routine runs for
a
> bulk usb read, the target freezes and windbg (and kd) fails to break into
> the debugger. I know it’s stuck in the completion routine, because of the
> debug output statements I see. My only recourse at that point is to
> physically reset the target, and I don’t get to see the information I’m
> interested in.
>
> I’ve gotten about as far as I can debugging this driver using DbgPrint
> statements and would like to actually use windbg (or even kd).
>
> Any suggestions as to how I can get this working would be greatly
> appreciated.

In addition to Sandy’s recommendations, have you tried putting a breakpoint
at the beginning of your completion routine? If nothing else works, bu
MyDriver!MyCompletionRoutine should.

You don’t mention what your host and target OS’es are, or if you are using
serial or 1394. If you are using 1394, completely disable the 1394 adapter
in the Device Mangler on the target. Additionally, you might be able to
resurrect what appears to be a completely hung setup by resynchronizing the
connection. I’ve also recovered sessions by unplugging and reinserting the
1394 cable. Search the archive for this mailing list and google the
microsoft.public.windbg newsgroup for more on that topic.

Phil

Philip D. Barila Windows DDK MVP
Seagate Technology, LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.

Please expand more on the suggestion of using a slower baud rate on the
serial line. I want to know more about machine characteristics. I
heartly welcome more knowledge since I’m experiencing hangs on two
different machine models. I’ll share what I’ve learned so far in hopes
it will help.

I’ve found different results depending on the machine model of
the target. I use the same the machine, a 2GHZ, as the debugger
machine. The debugee/target machine is either a 450 MHZ or a 1GHZ. On
my old faithful target (450 MHZ Dual proc), for hangs using Windbg , I
send a kernel debug break again from the drop down list using the GUI
interface, not windbg command line entry. This causes a response. If I
don’t do this and just try issuing more commands from the windbg command
line, the machine does not respond. It is hung. This technique works
pretty well in most cases. On my troublesome newer machine (1GHZ), I
see a different behavior. The machine gets stuck/hung, and I’m not sure
how to fix it. I’ll try the suggestions of different serial line
speeds. Both machines are running same OS, same set of drivers.

So, if you are seeing your machine hung in the debugger, you may
want to see if that same behavior happens on another machine of
different characteristics. That gives you another piece of information
in the problem solving.

Barb

-----Original Message-----
From: Sandy Spinrad [mailto:xxxxx@windows.microsoft.com]
Sent: Thursday, July 24, 2003 2:17 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Target machine hangs without breaking into
debugger

I could be stating the obvious here, but have you enabled driver
verifier on your driver, and any stacks that your driver is attached to
(e.g. usb)?

It’s possible that the driver verifier might catch a failure before it
takes out the system (assuming that your driver is taking out the
system).

Also using checked builds of the kernel / corresponding stacks may also
provide additional hints of what’s going wrong. Likewise testing on a
newer o/s release (assuming that you’re testing on an older o/s release
like W2K) might also expose the problem.

Or it could be something that has to do with the debugger. Make sure
you’re using the latest windbg/kd. And if you’re running over serial
try a slower baud rate. If you’re running over 1394, try disabling the
1394 port on the target system.

–Sandy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Linda Marcellus
Sent: Thursday, July 24, 2003 1:09 PM
To: Kernel Debugging Interest List
Subject: [windbg] Target machine hangs without breaking into debugger

Hi,

I’m having trouble using windbg (and even just kd) to debug a driver
that I’ve written.

If I don’t have windbg or kd running on my host, I can open a handle to
my driver, and it can send bulk usb read requests down the usb stack and
complete them without problems.

However, if I have windbg or kd running and have managed to break into
the debugger and load symbols etc (but haven’t set any breakpoints),
then I can open a handle to my driver, but as soon as the completion
routine runs for a bulk usb read, the target freezes and windbg (and kd)
fails to break into the debugger. I know it’s stuck in the completion
routine, because of the debug output statements I see. My only recourse
at that point is to physically reset the target, and I don’t get to see
the information I’m interested in.

I’ve gotten about as far as I can debugging this driver using DbgPrint
statements and would like to actually use windbg (or even kd).

Any suggestions as to how I can get this working would be greatly
appreciated.

Thanks,
Linda


You are currently subscribed to windbg as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: barbara.leahy@hp.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

On host, you set the serial line baudrate. When you selected Kernel
Debug from File menu in Com tab.

On target, you set the baudrate in your boot.ini using /baudrate=xxxx

The baudrate specified at the host and target should be the same. Look
windbg documentation for valid baudrate values…

-Srin.

-----Original Message-----
From: Leahy, Barbara C [mailto:barbara.leahy@hp.com]
Sent: Friday, July 25, 2003 7:50 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Target machine hangs without breaking into
debugger

Please expand more on the suggestion of using a slower baud rate on
the
serial line. I want to know more about machine characteristics. I
heartly welcome more knowledge since I’m experiencing hangs on two
different machine models. I’ll share what I’ve learned so far in
hopes
it will help.

I’ve found different results depending on the machine model of
the target. I use the same the machine, a 2GHZ, as the debugger
machine. The debugee/target machine is either a 450 MHZ or a 1GHZ.
On
my old faithful target (450 MHZ Dual proc), for hangs using Windbg , I
send a kernel debug break again from the drop down list using the GUI
interface, not windbg command line entry. This causes a response. If
I
don’t do this and just try issuing more commands from the windbg
command
line, the machine does not respond. It is hung. This technique works
pretty well in most cases. On my troublesome newer machine (1GHZ), I
see a different behavior. The machine gets stuck/hung, and I’m not
sure
how to fix it. I’ll try the suggestions of different serial line
speeds. Both machines are running same OS, same set of drivers.

So, if you are seeing your machine hung in the debugger, you may
want to see if that same behavior happens on another machine of
different characteristics. That gives you another piece of
information
in the problem solving.

Barb

-----Original Message-----
From: Sandy Spinrad [mailto:xxxxx@windows.microsoft.com]
Sent: Thursday, July 24, 2003 2:17 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Target machine hangs without breaking into
debugger

I could be stating the obvious here, but have you enabled driver
verifier on your driver, and any stacks that your driver is attached
to
(e.g. usb)?

It’s possible that the driver verifier might catch a failure before it
takes out the system (assuming that your driver is taking out the
system).

Also using checked builds of the kernel / corresponding stacks may
also
provide additional hints of what’s going wrong. Likewise testing on a
newer o/s release (assuming that you’re testing on an older o/s
release
like W2K) might also expose the problem.

Or it could be something that has to do with the debugger. Make sure
you’re using the latest windbg/kd. And if you’re running over serial
try a slower baud rate. If you’re running over 1394, try disabling
the
1394 port on the target system.

–Sandy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Linda Marcellus
Sent: Thursday, July 24, 2003 1:09 PM
To: Kernel Debugging Interest List
Subject: [windbg] Target machine hangs without breaking into debugger

Hi,

I’m having trouble using windbg (and even just kd) to debug a driver
that I’ve written.

If I don’t have windbg or kd running on my host, I can open a handle
to
my driver, and it can send bulk usb read requests down the usb stack
and
complete them without problems.

However, if I have windbg or kd running and have managed to break into
the debugger and load symbols etc (but haven’t set any breakpoints),
then I can open a handle to my driver, but as soon as the completion
routine runs for a bulk usb read, the target freezes and windbg (and
kd)
fails to break into the debugger. I know it’s stuck in the completion
routine, because of the debug output statements I see. My only
recourse
at that point is to physically reset the target, and I don’t get to
see
the information I’m interested in.

I’ve gotten about as far as I can debugging this driver using DbgPrint
statements and would like to actually use windbg (or even kd).

Any suggestions as to how I can get this working would be greatly
appreciated.

Thanks,
Linda


You are currently subscribed to windbg as:
xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: barbara.leahy@hp.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@nai.com
To unsubscribe send a blank email to xxxxx@lists.osr.com