connecting debugger

NTDEV
1

Hello!

I have set up my target machine (WinXP SP2), written the boot.ini line in
the target machine:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“Microsoft Windows XP
Professional” /noexecute=optin /fastdetect /redirect
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“Microsoft Windows XP
Professional” DEBUGPORT=COM1 /BAUDRATE=115200 /noexecute=optin /fastdetect

I have setup WinDBG to connect to my target machine with the same baudrate,
and when I try to connect the debugger it never connects to the target.

On the other hand, if I use hyperterminal on both machines to test the
serial connection everything goes fine in both senses.

I have used the same WinDBG to debug a kernel in a Virtual machine installed
in the same host machine and eveything goes fine, i have noticed that when I
start WinXP (in the VM) with debugger enabled the COM1 port disappears from
the device manager, on the other hand, when I start the *real* target
machine the COM port is always there.

I have searched thru the list and I have only found one clue about disabling
the ‘Legacy USB’ support on the target machine BIOS because it seemed to
have bad interactions with the kernel debugger module in the target, I did
it but nothing changed.

Do you have any idea of what could be the issue here… other things to try?

Thanks all
Nestor.

2

If the missing / before debugport an artifact of email, or is it missing in
the boot.ini?

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

“Nestor Lopez” wrote in message
news:xxxxx@ntdev…
> Hello!
>
> I have set up my target machine (WinXP SP2), written the boot.ini line in
> the target machine:
>
> [boot loader]
> timeout=30
> default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
> [operating systems]
> multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“Microsoft Windows XP
> Professional” /noexecute=optin /fastdetect /redirect
> multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“Microsoft Windows XP
> Professional” DEBUGPORT=COM1 /BAUDRATE=115200 /noexecute=optin /fastdetect
>
> I have setup WinDBG to connect to my target machine with the same
> baudrate, and when I try to connect the debugger it never connects to the
> target.
>
> On the other hand, if I use hyperterminal on both machines to test the
> serial connection everything goes fine in both senses.
>
> I have used the same WinDBG to debug a kernel in a Virtual machine
> installed in the same host machine and eveything goes fine, i have noticed
> that when I start WinXP (in the VM) with debugger enabled the COM1 port
> disappears from the device manager, on the other hand, when I start the
> real target machine the COM port is always there.
>
> I have searched thru the list and I have only found one clue about
> disabling the ‘Legacy USB’ support on the target machine BIOS because it
> seemed to have bad interactions with the kernel debugger module in the
> target, I did it but nothing changed.
>
> Do you have any idea of what could be the issue here… other things to
> try?
>
> Thanks all
> Nestor.
>
>

3

Ha, you were right, it was an error in the boot.ini file, now it is
corrected, I restarted the target machine and the COM1 port in the device
manager is gone which I interpret as good news (i guess it is taken by the
debugger module) but anyway my WinDbg still says…

Microsoft (R) Windows Debugger Version 6.6.0003.5
Copyright (c) Microsoft Corporation. All rights reserved.

Opened \.\COM4
Waiting to reconnect…

And it stays there…

If there is another idea…
Thanks…
Nestor.

“Don Burn” wrote in message news:xxxxx@ntdev…
> If the missing / before debugport an artifact of email, or is it missing
> in the boot.ini?
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
> “Nestor Lopez” wrote in message
> news:xxxxx@ntdev…
>> Hello!
>>
>> I have set up my target machine (WinXP SP2), written the boot.ini line in
>> the target machine:
>>
>> [boot loader]
>> timeout=30
>> default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
>> [operating systems]
>> multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“Microsoft Windows XP
>> Professional” /noexecute=optin /fastdetect /redirect
>> multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“Microsoft Windows XP
>> Professional” DEBUGPORT=COM1 /BAUDRATE=115200 /noexecute=optin
>> /fastdetect
>>
>> I have setup WinDBG to connect to my target machine with the same
>> baudrate, and when I try to connect the debugger it never connects to the
>> target.
>>
>> On the other hand, if I use hyperterminal on both machines to test the
>> serial connection everything goes fine in both senses.
>>
>> I have used the same WinDBG to debug a kernel in a Virtual machine
>> installed in the same host machine and eveything goes fine, i have
>> noticed that when I start WinXP (in the VM) with debugger enabled the
>> COM1 port disappears from the device manager, on the other hand, when I
>> start the real target machine the COM port is always there.
>>
>> I have searched thru the list and I have only found one clue about
>> disabling the ‘Legacy USB’ support on the target machine BIOS because it
>> seemed to have bad interactions with the kernel debugger module in the
>> target, I did it but nothing changed.
>>
>> Do you have any idea of what could be the issue here… other things to
>> try?
>>
>> Thanks all
>> Nestor.
>>
>>
>
>
>

4

NESTOR:

Are you missing the slash ‘/’ before /DEBUGPORT or is that an artifact
of the e-mail? Also, you haven’t a /DEBUG switch, which may be OK
considering the /DEBUGPORT is there. As I don’t know, and it won’t
hurt, you might give it a try. Finally, you there is neither a /BREAK
nor a /HALBREAKPOINT, so you need to either starting WinDbg with -b
and/or -d, or manually requesting it to break in.

OK, one more thing. It has been quite a while since I’ve used WinDbg
over COM, but I seem to recall having issues sometimes at higher baud
rates. If none of the above work, you might try lowering to 19200 (on
both ends) and see what happens.

FYI, you probably already know this, but just in case, unless you have
real need to do so, getting a 1394 connection would one of the biggest
favors you could do yourself. I haven’t any idea of what the USB
support is like, except to say that it is too difficult to find a cable
for me to give a run.

MM

>> xxxxx@yahoo.com 2006-09-08 10:33 >>>
Hello!

I have set up my target machine (WinXP SP2), written the boot.ini line
in
the target machine:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“Microsoft Windows XP
Professional” /noexecute=optin /fastdetect /redirect
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“Microsoft Windows XP
Professional” DEBUGPORT=COM1 /BAUDRATE=115200 /noexecute=optin
/fastdetect

I have setup WinDBG to connect to my target machine with the same
baudrate,
and when I try to connect the debugger it never connects to the
target.

On the other hand, if I use hyperterminal on both machines to test the

serial connection everything goes fine in both senses.

I have used the same WinDBG to debug a kernel in a Virtual machine
installed
in the same host machine and eveything goes fine, i have noticed that
when I
start WinXP (in the VM) with debugger enabled the COM1 port disappears
from
the device manager, on the other hand, when I start the *real* target
machine the COM port is always there.

I have searched thru the list and I have only found one clue about
disabling
the ‘Legacy USB’ support on the target machine BIOS because it seemed
to
have bad interactions with the kernel debugger module in the target, I
did
it but nothing changed.

Do you have any idea of what could be the issue here… other things to
try?

Thanks all
Nestor.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

“Martin O’Brien” wrote in message
> FYI, you probably already know this, but just in case, unless you have
> real need to do so, getting a 1394 connection would one of the biggest
> favors you could do yourself. I haven’t any idea of what the USB
> support is like, except to say that it is too difficult to find a cable
> for me to give a run.
>
Martin,

It is still the case that serial is the most solid, 1394 is pretty
solid (though the last version of WinDBG seems to have back slid) and USB is
an interesting challenge. When you look at the restrictions on using USB
you wonder why anyone would if they have a choice.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

6

DON:

Just curious. What are the restrictions? I was originally interested
in it as a way connect without an additional 1394 card, as most any
machine that I have to work on other my test machines (which is fairly
rare, but does happen) is more or less guaranteed not to have a 1394
port, and will almost certainly have a USB that can be disabled without
causing and issues. That was until I spent I don’t know how long trying
to find a cable, and came to the conclusion that the no 1394 port
sounded nice, but not being able to buy a cable in a pinch (which is
when I need them) is much worse, so I never even got as far as
stability.

MM

>> xxxxx@acm.org 2006-09-08 15:50 >>>

“Martin O’Brien” wrote in message
> FYI, you probably already know this, but just in case, unless you
have
> real need to do so, getting a 1394 connection would one of the
biggest
> favors you could do yourself. I haven’t any idea of what the USB
> support is like, except to say that it is too difficult to find a
cable
> for me to give a run.
>
Martin,

It is still the case that serial is the most solid, 1394 is pretty

solid (though the last version of WinDBG seems to have back slid) and
USB is
an interesting challenge. When you look at the restrictions on using
USB
you wonder why anyone would if they have a choice.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

7

The restriction that the cable must be plugged into the port 1 of the root
hub of the first USB controller on the system. I spoken to folks who
discoved that port wasn’t available on their machine, since the manufacturer
had uses it for something rather than bring it out.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> DON:
>
> Just curious. What are the restrictions? I was originally interested
> in it as a way connect without an additional 1394 card, as most any
> machine that I have to work on other my test machines (which is fairly
> rare, but does happen) is more or less guaranteed not to have a 1394
> port, and will almost certainly have a USB that can be disabled without
> causing and issues. That was until I spent I don’t know how long trying
> to find a cable, and came to the conclusion that the no 1394 port
> sounded nice, but not being able to buy a cable in a pinch (which is
> when I need them) is much worse, so I never even got as far as
> stability.
>
> MM
>
>>>> xxxxx@acm.org 2006-09-08 15:50 >>>
>
> “Martin O’Brien” wrote in message
>> FYI, you probably already know this, but just in case, unless you
> have
>> real need to do so, getting a 1394 connection would one of the
> biggest
>> favors you could do yourself. I haven’t any idea of what the USB
>> support is like, except to say that it is too difficult to find a
> cable
>> for me to give a run.
>>
> Martin,
>
> It is still the case that serial is the most solid, 1394 is pretty
>
> solid (though the last version of WinDBG seems to have back slid) and
> USB is
> an interesting challenge. When you look at the restrictions on using
> USB
> you wonder why anyone would if they have a choice.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

8

USB support is limited as to the platforms it’s available on as well. Not to mention the cables are EXPENSIVE: http://www.osronline.com/article.cfm?article=456

Peter
OSR

9

Thanks everybody,

WinDBG -b -d solved the problem, I’m still at 115200 everything OK.
I’m very pleased and impressed by the spirit and seriousness of this forum.

I hope to contribute as well.
Nestor.

“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> NESTOR:
>
> Are you missing the slash ‘/’ before /DEBUGPORT or is that an artifact
> of the e-mail? Also, you haven’t a /DEBUG switch, which may be OK
> considering the /DEBUGPORT is there. As I don’t know, and it won’t
> hurt, you might give it a try. Finally, you there is neither a /BREAK
> nor a /HALBREAKPOINT, so you need to either starting WinDbg with -b
> and/or -d, or manually requesting it to break in.
>
> OK, one more thing. It has been quite a while since I’ve used WinDbg
> over COM, but I seem to recall having issues sometimes at higher baud
> rates. If none of the above work, you might try lowering to 19200 (on
> both ends) and see what happens.
>
> FYI, you probably already know this, but just in case, unless you have
> real need to do so, getting a 1394 connection would one of the biggest
> favors you could do yourself. I haven’t any idea of what the USB
> support is like, except to say that it is too difficult to find a cable
> for me to give a run.
>
> MM
>
>>>> xxxxx@yahoo.com 2006-09-08 10:33 >>>
> Hello!
>
> I have set up my target machine (WinXP SP2), written the boot.ini line
> in
> the target machine:
>
> [boot loader]
> timeout=30
> default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
> [operating systems]
> multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“Microsoft Windows XP
> Professional” /noexecute=optin /fastdetect /redirect
> multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“Microsoft Windows XP
> Professional” DEBUGPORT=COM1 /BAUDRATE=115200 /noexecute=optin
> /fastdetect
>
> I have setup WinDBG to connect to my target machine with the same
> baudrate,
> and when I try to connect the debugger it never connects to the
> target.
>
> On the other hand, if I use hyperterminal on both machines to test the
>
> serial connection everything goes fine in both senses.
>
> I have used the same WinDBG to debug a kernel in a Virtual machine
> installed
> in the same host machine and eveything goes fine, i have noticed that
> when I
> start WinXP (in the VM) with debugger enabled the COM1 port disappears
> from
> the device manager, on the other hand, when I start the real target
> machine the COM port is always there.
>
> I have searched thru the list and I have only found one clue about
> disabling
> the ‘Legacy USB’ support on the target machine BIOS because it seemed
> to
> have bad interactions with the kernel debugger module in the target, I
> did
> it but nothing changed.
>
> Do you have any idea of what could be the issue here… other things to
> try?
>
> Thanks all
> Nestor.
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>