Sharing COM1 with WinDbg
in [Device Drivers]
|
From: Michael on 5 May 2008 10:59 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!
From: Doron Holan [MSFT] on 5 May 2008 13:28 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(a)discussions.microsoft.com> wrote in message news:96823F6F-ECBE-45FA-B50C-49D6093DCC03(a)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!
From: Pavel A. on 5 May 2008 14:30 Does this machine have USB? If yes, USB to serial adapter can help. --PA "Michael" <Michael(a)discussions.microsoft.com> wrote in message news:96823F6F-ECBE-45FA-B50C-49D6093DCC03(a)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!
From: Doron Holan [MSFT] on 5 May 2008 20:00 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(a)NOwritemeNO.com> wrote in message news:%23eXXz5trIHA.4560(a)TK2MSFTNGP03.phx.gbl... > Does this machine have USB? If yes, USB to serial adapter can help. > > --PA > > > "Michael" <Michael(a)discussions.microsoft.com> wrote in message > news:96823F6F-ECBE-45FA-B50C-49D6093DCC03(a)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! >
From: Pavel A. on 6 May 2008 17:15 "Doron Holan [MSFT]" <doronh(a)online.microsoft.com> wrote in message news:uKDQ1wwrIHA.1200(a)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(a)NOwritemeNO.com> wrote in message > news:%23eXXz5trIHA.4560(a)TK2MSFTNGP03.phx.gbl... >> Does this machine have USB? If yes, USB to serial adapter can help. >> >> --PA >> >> >> "Michael" <Michael(a)discussions.microsoft.com> wrote in message >> news:96823F6F-ECBE-45FA-B50C-49D6093DCC03(a)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! >> >
|
Pages: 1 Prev: IoCallDriver Bugcheck Next: Test cases for WLAN SDIO interface |