Wingbg

I was wondering if anyone could offer me a clue.

I just trying to get the test system up. Every time I
select kernel debugging from the dev system and go the
test system freezes but the Windbg on the dev system
isn’t accepting it.

When I do the reverse and try to debug the dev system
from the test system it works perfectly fine, even at
115200. Any clues?

First make sure you are using the latest Windbg at
http://www.microsoft.com/ddk/debugging
I don’t think what you are experiencing is a Windbg problem, but the
latest version (which hit the web today) rocks.

It sounds like you have some kind of setup issue. Like perhaps you
aren’t removing the /debug on the dev system when you attempt to debug
from it, thus causing the com port to be unavailable.

It’s really hard to say as your description of the problem is rather
vague.

If you need more help resolving the issue after trying the new Windbg
and looking over the docs (in the new debugger package), then please
e-mail me.

Enjoy

-----Original Message-----
From: Chris Telting [mailto:xxxxx@mindspring.com]
Sent: Wednesday, September 20, 2000 9:18 PM
To: NT Developers Interest List
Subject: [ntdev] Wingbg

I was wondering if anyone could offer me a clue.

I just trying to get the test system up. Every time I
select kernel debugging from the dev system and go the
test system freezes but the Windbg on the dev system
isn’t accepting it.

When I do the reverse and try to debug the dev system
from the test system it works perfectly fine, even at
115200. Any clues?


You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

> First make sure you are using the latest Windbg at

http://www.microsoft.com/ddk/debugging I don’t think what
you are experiencing is a Windbg problem, but the latest
version (which hit the web today) rocks. It sounds like you
have some kind of setup issue. Like perhaps you aren’t
removing the /debug on the dev system when you attempt to
debug from it, thus causing the com port to be unavailable.
It’s really hard to say as your description of the problem is
rather vague.

If you need more help resolving the issue after trying the new
Windbg and looking over the docs (in the new debugger
package), then please e-mail me.

First of all Thanks for replying. I am quite convinced it is a setup issue but I don’t
know how to resolve it. The problem is only on a particular old machine.

First of all reinstalled a fresh OS and then appled SP1 on the test machine.

After setting up boot.ini with the proper debug parameters I reboot. If I try to initiate
debugging the test machine it just freezes like you would expect. The only problem is
that Windbg isn’t syncing with it. I can .resync and will retry but it never really
establishes the connection.

On further analysis I discoved that in device manager on the test machine that when I boot
with the debug parameter on one of the com ports(it doesn’t matter which one) that
perticular com port in device manager still exists with a exclmation point conflict. The
IO port range conflicts with the “Standard PC” device. But the IRQ is perfectly fine.
The problem is only on this one machine when I boot with a debug parameter.

I searched deja with “/debugport” and “Standard PC” and some russian guy evidently had the
same problem.

Nothing is wrong with the com ports as I can debug the dev computer from the test computer
just fine. Could this just be a kernel problem on older computers?

If you are using .resync, then you have a very old vesion of WinDBG.
Please get the latest version of WinDBG from
http://www.microsoft.com/ddk/debugging

-Andre

>On further analysis I discoved that in device manager on the test
machine that when I boot

with the debug parameter on one of the com ports(it doesn’t matter
which one) that
perticular com port in device manager still exists with a exclmation
point conflict. The
IO port range conflicts with the “Standard PC” device. But the IRQ is
perfectly fine.
The problem is only on this one machine when I boot with a debug
parameter.

It is normal for the com port on the target that is being used for
debugging to be banged out or even missing. The quick explaination is
that the debugger takes control of it, so the COM port driver marks it
is unavailable.

As Andreva said, .resync a command that is long gone. Try the latest
debuggers. and read the DOCS.

-----Original Message-----
From: Chris Telting [mailto:xxxxx@mindspring.com]
Sent: Thursday, September 21, 2000 11:43 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Wingbg

First make sure you are using the latest Windbg at
http://www.microsoft.com/ddk/debugging I don’t think what
you are experiencing is a Windbg problem, but the latest
version (which hit the web today) rocks. It sounds like you
have some kind of setup issue. Like perhaps you aren’t
removing the /debug on the dev system when you attempt to
debug from it, thus causing the com port to be unavailable.
It’s really hard to say as your description of the problem is
rather vague.

If you need more help resolving the issue after trying the new
Windbg and looking over the docs (in the new debugger
package), then please e-mail me.

First of all Thanks for replying. I am quite convinced it is a setup
issue but I don’t
know how to resolve it. The problem is only on a particular old
machine.

First of all reinstalled a fresh OS and then appled SP1 on the test
machine.

After setting up boot.ini with the proper debug parameters I reboot. If
I try to initiate
debugging the test machine it just freezes like you would expect. The
only problem is
that Windbg isn’t syncing with it. I can .resync and will retry but it
never really
establishes the connection.

On further analysis I discoved that in device manager on the test
machine that when I boot
with the debug parameter on one of the com ports(it doesn’t matter which
one) that
perticular com port in device manager still exists with a exclmation
point conflict. The
IO port range conflicts with the “Standard PC” device. But the IRQ is
perfectly fine.
The problem is only on this one machine when I boot with a debug
parameter.

I searched deja with “/debugport” and “Standard PC” and some russian guy
evidently had the
same problem.

Nothing is wrong with the com ports as I can debug the dev computer from
the test computer
just fine. Could this just be a kernel problem on older computers?


You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)