Debugging an IFS driver with Windbg

I’m a Softice user trying to setup windbg for debugging my IFS. I verified
my serial null-modem connection via hyperterminal but cannot get the host
to connect to the target machine. The host never gets past, “Waiting to
reconnect…”

My configuration:

HOST -
Windows 2000
Windbg version 4.0.0018.0
set _NT_DEBUG_BAUD_RATE=19200
set _NT_DEBUG_PORT=com1
command line “start windbg -k”

TARGET -
Windows 2000 sp2
boot.ini settings, “/debug /baudrate=19200 /debugport=com1”

Also, I noticed that COM1 still shows up in device manager (on the raget
machine). Shouldn’t the debugger mask the serial port being used by the
debugger?

Any ideas?


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

The /debug command in boot.ini indicates to NT that it will take over com1
when the system hits a breakpoint or crashes. The doc says:

Allows the computer to be debugged. If a kernel debugger attaches to this
computer it will be given control over its execution. If a bug check occurs,
or if a kernel-mode program attempts to communicate with a debugger, the
computer will pause and wait for a response from a kernel debugger.
The debug option should be used if you are performing local kernel
debugging. If you are debugging over a COM port, you should use debugport
and baudrate instead. If you are debugging over a 1394 cable, you should use
debugport and channel instead.

So, get rid of the /debug and you should be okay.

-----Original Message-----
From: xxxxx@charter.net [mailto:xxxxx@charter.net]
Sent: Wednesday, January 23, 2002 12:00 PM
To: File Systems Developers
Subject: [ntfsd] Debugging an IFS driver with Windbg

I’m a Softice user trying to setup windbg for debugging my IFS. I verified
my serial null-modem connection via hyperterminal but cannot get the host
to connect to the target machine. The host never gets past, “Waiting to
reconnect…”

My configuration:

HOST -
Windows 2000
Windbg version 4.0.0018.0
set _NT_DEBUG_BAUD_RATE=19200
set _NT_DEBUG_PORT=com1
command line “start windbg -k”

TARGET -
Windows 2000 sp2
boot.ini settings, “/debug /baudrate=19200 /debugport=com1”

Also, I noticed that COM1 still shows up in device manager (on the raget
machine). Shouldn’t the debugger mask the serial port being used by the
debugger?

Any ideas?


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

I tried to remove the “\debug” option from the boot.ini but still cannot
connect the debugger. COM1 is still not masked either.

Hmmmmmmmm?


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

And, unless the UART won’t support it, I’d recommend you bump the baud
rate up to 115200. I’ve used a variety of systems over the last few
years at this baud rate with no problems.

-----Original Message-----
From: Mark Cariddi [mailto:xxxxx@osr.com]
Sent: Wednesday, January 23, 2002 5:06 PM
To: File Systems Developers
Subject: [ntfsd] RE: Debugging an IFS driver with Windbg

The /debug command in boot.ini indicates to NT that it will take over
com1
when the system hits a breakpoint or crashes. The doc says:

Allows the computer to be debugged. If a kernel debugger attaches to
this
computer it will be given control over its execution. If a bug check
occurs,
or if a kernel-mode program attempts to communicate with a debugger, the
computer will pause and wait for a response from a kernel debugger.
The debug option should be used if you are performing local kernel
debugging. If you are debugging over a COM port, you should use
debugport
and baudrate instead. If you are debugging over a 1394 cable, you should
use
debugport and channel instead.

So, get rid of the /debug and you should be okay.

-----Original Message-----
From: xxxxx@charter.net [mailto:xxxxx@charter.net]
Sent: Wednesday, January 23, 2002 12:00 PM
To: File Systems Developers
Subject: [ntfsd] Debugging an IFS driver with Windbg

I’m a Softice user trying to setup windbg for debugging my IFS. I
verified
my serial null-modem connection via hyperterminal but cannot get the
host
to connect to the target machine. The host never gets past, "Waiting to

reconnect…"

My configuration:

HOST -
Windows 2000
Windbg version 4.0.0018.0
set _NT_DEBUG_BAUD_RATE=19200
set _NT_DEBUG_PORT=com1
command line “start windbg -k”

TARGET -
Windows 2000 sp2
boot.ini settings, “/debug /baudrate=19200 /debugport=com1”

Also, I noticed that COM1 still shows up in device manager (on the raget

machine). Shouldn’t the debugger mask the serial port being used by the

debugger?

Any ideas?


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@nsisoftware.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Just to cover all the basics (don’t take offense if it is too simple.
Just want to make sure we are all on the same page.)

The machine to be debugged is the TARGET
The machine where windbg runs is the HOST

Are you changing the boot.ini on the TARGET?
Are you rebooting TARGET after changing boot.ini? Changes only
take affect after a reboot.
If multiple menu items exist at the OSChooser on the TARGET are
you picking the one with the debug stuff?
Win2k/WinXP - If you hit F8 and pick debug mode from the menu,
does it work?

To verify what you are seeing:
COM1 is still listed in device manager and is not banged out on
the TARGET
An app like Hyperterm running on the TARGET can access COM1

A clarification on the device manger thing. The com port may disappear
or be banged out. Which happens depends on what type of BIOS you have.
Either is expected on a machine booted for debugging.

-----Original Message-----
From: xxxxx@charter.net [mailto:xxxxx@charter.net]
Sent: Wednesday, January 23, 2002 11:24 AM
To: File Systems Developers
Subject: [ntfsd] RE: Debugging an IFS driver with Windbg

I tried to remove the “\debug” option from the boot.ini but still cannot

connect the debugger. COM1 is still not masked either.

Hmmmmmmmm?


You are currently subscribed to ntfsd as: xxxxx@microsoft.com To
unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Several old P5 machines hold this rate fine.

----- Original Message -----
From: “Kelley, Jerry”
To: “File Systems Developers”
Sent: Thursday, January 24, 2002 3:28 AM
Subject: [ntfsd] RE: Debugging an IFS driver with Windbg

And, unless the UART won’t support it, I’d recommend you bump the baud
rate up to 115200. I’ve used a variety of systems over the last few
years at this baud rate with no problems.

-----Original Message-----
From: Mark Cariddi [mailto:xxxxx@osr.com]
Sent: Wednesday, January 23, 2002 5:06 PM
To: File Systems Developers
Subject: [ntfsd] RE: Debugging an IFS driver with Windbg

The /debug command in boot.ini indicates to NT that it will take over
com1
when the system hits a breakpoint or crashes. The doc says:

Allows the computer to be debugged. If a kernel debugger attaches to
this
computer it will be given control over its execution. If a bug check
occurs,
or if a kernel-mode program attempts to communicate with a debugger, the
computer will pause and wait for a response from a kernel debugger.
The debug option should be used if you are performing local kernel
debugging. If you are debugging over a COM port, you should use
debugport
and baudrate instead. If you are debugging over a 1394 cable, you should
use
debugport and channel instead.

So, get rid of the /debug and you should be okay.

-----Original Message-----
From: xxxxx@charter.net [mailto:xxxxx@charter.net]
Sent: Wednesday, January 23, 2002 12:00 PM
To: File Systems Developers
Subject: [ntfsd] Debugging an IFS driver with Windbg

I’m a Softice user trying to setup windbg for debugging my IFS. I
verified
my serial null-modem connection via hyperterminal but cannot get the
host
to connect to the target machine. The host never gets past, “Waiting to

reconnect…”

My configuration:

HOST -
Windows 2000
Windbg version 4.0.0018.0
set _NT_DEBUG_BAUD_RATE=19200
set _NT_DEBUG_PORT=com1
command line “start windbg -k”

TARGET -
Windows 2000 sp2
boot.ini settings, “/debug /baudrate=19200 /debugport=com1”

Also, I noticed that COM1 still shows up in device manager (on the raget

machine). Shouldn’t the debugger mask the serial port being used by the

debugger?

Any ideas?


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@nsisoftware.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

I added “\fastdetect” as a boot option and COM1 is no longer visable from
Device Manager. But, I still cannot connect to the HOST.

Here’s the answers to your questions…

Are you changing the boot.ini on the TARGET? [Yes]

Are you rebooting TARGET after changing boot.ini? Changes only
take affect after a reboot. [Yes]

If multiple menu items exist at the OSChooser on the TARGET are
you picking the one with the debug stuff? [Yes]

Win2k/WinXP - If you hit F8 and pick debug mode from the menu,
does it work? [No. Still unable to connect to the HOST.]

To verify what you are seeing:
COM1 is still listed in device manager and is not banged out on
the TARGET? [No. I put “/fastdetect” on the boot menu entry. Now COM1 is
no longer visable in Device Manager.]

An app like Hyperterm running on the TARGET can access COM1? [Not any more.
See previous answer.]

A clarification on the device manger thing. The com port may disappear
or be banged out. Which happens depends on what type of BIOS you have.
Either is expected on a machine booted for debugging.


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

So what OS is the TARGET running?

It sounds like everything is OK on the TARGET side, so lets look at the
host.

Have the TARGET running with your current setup (/fastdetect
/debugport=com1)
Make sure the cable is plugged into COM1 on the TARGET and COMX
(pick a port) on the HOST

Now start windbg with the following command line
windbg -k com:port=X
Where X is the COM port number the cable is connected to on the HOST

Then click the break button. Does anything happen?
If not then do CTRL+ALT+D, followed by CTRL+ALT+R

If you only get timeout messages then that means that the debugger is
getting no response from the TARGET.
If you are getting responses then you know you have your setup right and
the problem lies elsewhere.

-----Original Message-----
From: xxxxx@charter.net [mailto:xxxxx@charter.net]
Sent: Wednesday, January 23, 2002 5:00 PM
To: File Systems Developers
Subject: [ntfsd] RE: Debugging an IFS driver with Windbg

I added “\fastdetect” as a boot option and COM1 is no longer visable
from
Device Manager. But, I still cannot connect to the HOST.

Here’s the answers to your questions…

Are you changing the boot.ini on the TARGET? [Yes]

Are you rebooting TARGET after changing boot.ini? Changes only take
affect after a reboot. [Yes]

If multiple menu items exist at the OSChooser on the TARGET are you
picking the one with the debug stuff? [Yes]

Win2k/WinXP - If you hit F8 and pick debug mode from the menu, does it
work? [No. Still unable to connect to the HOST.]

To verify what you are seeing:
COM1 is still listed in device manager and is not banged out on the
TARGET? [No. I put “/fastdetect” on the boot menu entry. Now COM1 is
no longer visable in Device Manager.]

An app like Hyperterm running on the TARGET can access COM1? [Not any
more.
See previous answer.]

A clarification on the device manger thing. The com port may disappear
or be banged out. Which happens depends on what type of BIOS you have.
Either is expected on a machine booted for debugging.


You are currently subscribed to ntfsd as: xxxxx@microsoft.com To
unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

The OS on the TARGET is W2K SP2.

ctrl-alt-D, ctrl-alt-r gives a bunch of “SYNCTARGET: Timeout.”

I also tried a different target machine (this one with WinXP). I get the
same problem there too.


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Thank for the assistance. I figured this one out. The laptop that I was
using as the TARGET machine had the serial port disabled in the BIOS. It’s
interesting that I could still use Hyperterminal and the COM port was
displayed as active in DeviceManager. I guess Windbg queries the serial
port differently than other parts of the OS.


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

I think that makes sense even.

NTDETECT runs during boot and looks for the serial port by calling the system’s BIOS. This is probably done in Intel 16-bit real mode (shudder.) In order for you to kernel debug before the plug and play system is started, your debug port has to be found by NTDETECT through the BIOS.

When the system boots and the plug and play system walks all the buses, Windows finds that serial port you tried to hide in your BIOS settings.

-----Original Message-----
From: xxxxx@charter.net [mailto:xxxxx@charter.net]
Sent: Thursday, January 24, 2002 8:00 PM
To: File Systems Developers
Subject: [ntfsd] RE: Debugging an IFS driver with Windbg

Thank for the assistance. I figured this one out. The laptop that I was
using as the TARGET machine had the serial port disabled in the BIOS. It’s
interesting that I could still use Hyperterminal and the COM port was
displayed as active in DeviceManager. I guess Windbg queries the serial
port differently than other parts of the OS.


You are currently subscribed to ntfsd as: xxxxx@inin.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

> Thank for the assistance. I figured this one out. The laptop that I was

using as the TARGET machine had the serial port disabled in the BIOS. It’s
interesting that I could still use Hyperterminal and the COM port was
displayed as active in DeviceManager. I guess Windbg queries the serial
port differently than other parts of the OS.

On ACPI machines, all onboard hardware is displayed in Device Manager, even if disabled by BIOS. It will also be enabled in w2k
(like my 2 USB hosts on Asus CUSL2 mobo) even if disabled by BIOS. It must be re-disabled in w2k too.
But if the COM port is reserved for debugger, I expect ACPI to not awaken the hardware. Looks like KD relies on COM port to be “just
there” without having any actions to enable it.

Max


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com