Sharing COM1 with WinDbg

Michael

I have an embedded device running XPe with a single serial port (also no
1394). The COM1 port is normally used by applications for other purposes.
However, I would really like to be able to use this for kernel debugging as
well. I tried using /crashdebug option in boot.ini so that the COM1 port
does not disappear. The problem is that this does not let me debug on
demand, only when a bug check occurs. Is there a way to enable on demand
debugging without reserving the serial port for exclusive use by the
debugger? If not, the other option would be to have WinDbg monitor for
specific debug messages coming from the other machine. My understanding is
that this used to be possible with a .waitforstr command, but that doesn't
seem to be implemented any more. Is there a way to monitor messages from
within WinDbg?

Thanks!

Doron Holan [MSFT]

there is no way to share the com port the way you want to. you need to
either add another com port or 1394 controller.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Michael" <Michael@discussions.microsoft.com> wrote in message
news:96823F6F-ECBE-45FA-B50C-49D6093DCC03@microsoft.com...
>I have an embedded device running XPe with a single serial port (also no
> 1394). The COM1 port is normally used by applications for other purposes.
> However, I would really like to be able to use this for kernel debugging
> as
> well. I tried using /crashdebug option in boot.ini so that the COM1 port
> does not disappear. The problem is that this does not let me debug on
> demand, only when a bug check occurs. Is there a way to enable on demand
> debugging without reserving the serial port for exclusive use by the
> debugger? If not, the other option would be to have WinDbg monitor for
> specific debug messages coming from the other machine. My understanding
> is
> that this used to be possible with a .waitforstr command, but that doesn't
> seem to be implemented any more. Is there a way to monitor messages from
> within WinDbg?
>
> Thanks!

Pavel A.

Does this machine have USB? If yes, USB to serial adapter can help.

--PA


"Michael" <Michael@discussions.microsoft.com> wrote in message
news:96823F6F-ECBE-45FA-B50C-49D6093DCC03@microsoft.com...
> I have an embedded device running XPe with a single serial port (also no
> 1394). The COM1 port is normally used by applications for other purposes.
> However, I would really like to be able to use this for kernel debugging
> as
> well. I tried using /crashdebug option in boot.ini so that the COM1 port
> does not disappear. The problem is that this does not let me debug on
> demand, only when a bug check occurs. Is there a way to enable on demand
> debugging without reserving the serial port for exclusive use by the
> debugger? If not, the other option would be to have WinDbg monitor for
> specific debug messages coming from the other machine. My understanding
> is
> that this used to be possible with a .waitforstr command, but that doesn't
> seem to be implemented any more. Is there a way to monitor messages from
> within WinDbg?
>
> Thanks!

Doron Holan [MSFT]

to be a debugger host (e.g. run windbg) a usb serial adapter would help.
you cannot use such a device to be debugger target.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Pavel A." <pavel_a@NOwritemeNO.com> wrote in message
news:%23eXXz5trIHA.4560@TK2MSFTNGP03.phx.gbl...
> Does this machine have USB? If yes, USB to serial adapter can help.
>
> --PA
>
>
> "Michael" <Michael@discussions.microsoft.com> wrote in message
> news:96823F6F-ECBE-45FA-B50C-49D6093DCC03@microsoft.com...
>> I have an embedded device running XPe with a single serial port (also no
>> 1394). The COM1 port is normally used by applications for other
>> purposes.
>> However, I would really like to be able to use this for kernel debugging
>> as
>> well. I tried using /crashdebug option in boot.ini so that the COM1 port
>> does not disappear. The problem is that this does not let me debug on
>> demand, only when a bug check occurs. Is there a way to enable on demand
>> debugging without reserving the serial port for exclusive use by the
>> debugger? If not, the other option would be to have WinDbg monitor for
>> specific debug messages coming from the other machine. My understanding
>> is
>> that this used to be possible with a .waitforstr command, but that
>> doesn't
>> seem to be implemented any more. Is there a way to monitor messages from
>> within WinDbg?
>>
>> Thanks!
>

Pavel A.

"Doron Holan [MSFT]" <doronh@online.microsoft.com> wrote in message
news:uKDQ1wwrIHA.1200@TK2MSFTNGP03.phx.gbl...
> to be a debugger host (e.g. run windbg) a usb serial adapter would help.
> you cannot use such a device to be debugger target.
>

I meant using the USB adapter for the another app, and the real one for
debugger.

--PA

>
> "Pavel A." <pavel_a@NOwritemeNO.com> wrote in message
> news:%23eXXz5trIHA.4560@TK2MSFTNGP03.phx.gbl...
>> Does this machine have USB? If yes, USB to serial adapter can help.
>>
>> --PA
>>
>>
>> "Michael" <Michael@discussions.microsoft.com> wrote in message
>> news:96823F6F-ECBE-45FA-B50C-49D6093DCC03@microsoft.com...
>>> I have an embedded device running XPe with a single serial port (also no
>>> 1394). The COM1 port is normally used by applications for other
>>> purposes.
>>> However, I would really like to be able to use this for kernel debugging
>>> as
>>> well. I tried using /crashdebug option in boot.ini so that the COM1
>>> port
>>> does not disappear. The problem is that this does not let me debug on
>>> demand, only when a bug check occurs. Is there a way to enable on
>>> demand
>>> debugging without reserving the serial port for exclusive use by the
>>> debugger? If not, the other option would be to have WinDbg monitor for
>>> specific debug messages coming from the other machine. My understanding
>>> is
>>> that this used to be possible with a .waitforstr command, but that
>>> doesn't
>>> seem to be implemented any more. Is there a way to monitor messages
>>> from
>>> within WinDbg?
>>>
>>> Thanks!
>>
>