Debugging Help

Hi,
I am trying to debug a NDIS Miniport driver.

I have setup both Target and Host machines connected through NULL modem. I
have tested null moded using Hyper Terminal.

On the Host machine I am running WinDbg with Kernet Debugging on and it
gives the message "Waiting for connection ........".

On the Target machine I have changed the boot.ini to include my port
settings.

Now the problem is that most of the time it does not work. Nothing is
displayed on the WinDbg command window on Host machine. But sometimes it do
work and I can see the output. I tied rebooting the Target machine, but
nothing happens.

Sometimes when I press CTRL+C on the Host machine, my Target machine hangs.

Any ideas, why this random behaviour is happening????


JS

hannes
Mon Apr 25 11:00:03 CDT 2005

"Joga Singh" wrote:
> On the Host machine I am running WinDbg with Kernet Debugging on and it
> gives the message "Waiting for connection ........".

At this point, I usually press Ctrl-C a couple of times to "break into the
target".
If that does not work, cabling or settings are usually wrong. Also check
that you are using the correct COM port, and that it is enabled in BIOS, and
mapped to the correct IRQ and I/O address (also in BIOS).


> On the Target machine I have changed the boot.ini to include my port
> settings.

Like this? (added at end of long line)
.... /debugport=com1 /baudrate=115200

After making this change, you need to reboot the target machine. After
reboot, you can check in Device Manager on the target machine, that COM1 is
GONE. If it is gone (and was present before), your target machine is
correctly running in debug mode.


> Now the problem is that most of the time it does not work. Nothing is
> displayed on the WinDbg command window on Host machine. But sometimes it do
> work and I can see the output. I tied rebooting the Target machine, but
> nothing happens.

Press Ctrl-C a couple of times, reboot debugger machine...etc.


> Sometimes when I press CTRL+C on the Host machine, my Target machine hangs.

That is expected :-) as you are STOPPING the target machine by breaking into
it. That is correct behaviour, and means that you have everything set up
correctly.


> Any ideas, why this random behaviour is happening????

Once everything is properly set up, you should not see any "random
behaviour" - kernel debugging always seemed reliable and predictable to be.

/ Hannes.

Joga
Tue Apr 26 01:54:23 CDT 2005


"Hannes" <hannes.news@nospam.nospam> wrote in message
news:0CF8E6AC-8F00-4321-87A6-17AFA2A833D7@microsoft.com...
> "Joga Singh" wrote:
> > On the Host machine I am running WinDbg with Kernet Debugging on and it
> > gives the message "Waiting for connection ........".
>
> At this point, I usually press Ctrl-C a couple of times to "break into the
> target".
> If that does not work, cabling or settings are usually wrong. Also check
> that you are using the correct COM port, and that it is enabled in BIOS,
and
> mapped to the correct IRQ and I/O address (also in BIOS).

COM port seem to work fine. I have tested thrugh Hyper Terminal (after
disabling kernel debugging on Target Machine i.e. removed debugging fom
boot.ini)

>
> > On the Target machine I have changed the boot.ini to include my port
> > settings.
>
> Like this? (added at end of long line)
> .... /debugport=com1 /baudrate=115200

Yes. But I am not setting the baudrate. I suppose it takes the default
19200, I have the same rate set on the host.

> After making this change, you need to reboot the target machine. After
> reboot, you can check in Device Manager on the target machine, that COM1
is
> GONE. If it is gone (and was present before), your target machine is
> correctly running in debug mode.

Yes. COM1 disappears.

>
> > Now the problem is that most of the time it does not work. Nothing is
> > displayed on the WinDbg command window on Host machine. But sometimes it
do
> > work and I can see the output. I tied rebooting the Target machine, but
> > nothing happens.
>
> Press Ctrl-C a couple of times, reboot debugger machine...etc.
>
>
> > Sometimes when I press CTRL+C on the Host machine, my Target machine
hangs.
>
> That is expected :-) as you are STOPPING the target machine by breaking
into
> it. That is correct behaviour, and means that you have everything set up
> correctly.

What do you mean by "breaking into". What can I do on the target machine,
once I broke into it.

>
> > Any ideas, why this random behaviour is happening????
>
> Once everything is properly set up, you should not see any "random
> behaviour" - kernel debugging always seemed reliable and predictable to
be.
>
> / Hannes.

Could it be different version of WinDbg. I am running 5.xxxx which comes
with DDK 2000.

JS