>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’)