Hi,
For kernel debugging, you do not want to set any boot.ini options for
the host. You only set boot.ini options for the target (aka - victim).
When you set boot.ini options for any machine, the kernel on that
machine removes the comm port from use and instead uses it internally
for communication to a debugger. This is why you can’t use COM1 on the
host, it has effectively “disappeared” because the host machine thinks
you are going to connect Windbg to it, and the target also thinks you
are going to connect Windbg to it.
First boot everyone normal, and make sure that both PCs talk to each
other over hyperterm. Type in both hyperterm windows and make sure
you see it on the other machine (this makes sure the tx / rx lines are
connected good - I have seen cables with just one of the wires broke).
Then boot the host normal (no modified boot.ini), boot the target with
the debug boot.ini line, and then try to connect Windbg at 19,200 via
kernel debugging. I find that if a connection isn’t made immediately, I
can usually see debug output from the target as it’s booting anyway, and
if I execute a breakpoint in Windbg, this resyncs the comm.
Good luck!
-Mike
bank kus wrote:
Hi,
I have spent quite some time reading the documentation with windbg. However
it results in the following problems:
<1>
If i set /debug /debugport=COM1 /baudrate=19200 for the host
and
/debug /debugport=COM2 /baudrate=19200 for the target and boot,
at the host windbg says cannot connect to COM1. Also device manager does not
list COM1 but which i believe is
normal as mentioned in the docs.
<2>
If i keep the host a normal boot (non debug) and from inside windbg do
kernel debug on COM1 with baudrate, the host waits for connect on COM1.
but upon restarting (20 times literally) the target machine, it doesnt show
an iota of response. The target is booted with the same options as mentioned
above.
Did anybody have similar problems. Could there be something wrong with the
hardware, my host is a dell laptop.
thanks
bank kus
“Gary G. Little” wrote in message news:xxxxx@windbg…
>
>
>>This is well covered in the documentation.
>>
>>If you have Hyperterminal and can ZModem a file from one to the other,
>>then the serial link is working fine. At that point set the target for
>>debug by setting appropriate settings in the BOOT.INI file and reboot.
>>Start WinDbg on the host. Once the target reboots and begins loading the
>>OS you will see banner messages in the command window of WinDbg.
>>
>>Again, the documentation for WinDbg will tell you how to break into the
>>system. Just be sure that the bps you set in the targets INI file is the
>>same on the host WinDbg session.
>>
>>–
>>The personal opinion of
>>Gary G. Little
>>
>>“bank kus” wrote in message news:xxxxx@windbg…
>>
>>
>>>Hi,
>>>I am new to windbg (from softice). I have read some of the past mails
>>>regarding windbg with null modem connection.
>>>I havent been able to get the order right. Currently what I am doing is
>>>starting windbg on the host and then ctrl K to set the com port and baud
>>>rate. It says waiting to connect on COM1.
>>>Then I reboot the target system (with boot.ini changes). Here is what I
>>>dont understand, after rebooting, does the target start windbg
>>>automatically (pardon me if this is very naive and basic) or do I
>>>need to start Windbg with some key. When I start Windbg with windbg -k it
>>>says cannot connect to COM1. (thats the port reserved on the target)
>>> However, I am able to hyperterminal acroos the null modem cable.
>>>
>>>thanks
>>>bks
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
>—
>You are currently subscribed to windbg as: xxxxx@hologic.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>