> the only way I managed this was by running WinDbg from a
command line specifying the following:
start windbg -W Pipe -b -k com:pipe,port=\.\pipe\dbgpipe,resets=0
Thanks for replies, Peter and Spiro, at least I know that it may work as
I expected.
Strange, very strange…
My arrangements are exactly the same for both VPC (no
problems) and VMWare, I also figured out that there is no way
- for now, at least - to save the info about COM port being
redirected to a pipe in windbg’s workspace so that
we have to use prosthetics. In my case it is a dbgpipe.cmd
wich contains (I split the line)
“C:\Program Files\Debugging Tools for Windows\windbg.exe”
-y srv*D:\SYMBOLS*http://msdl.microsoft.com/download/symbols
-k com:pipe,port=\.\pipe\dbgpipe,resets=0,reconnect
(as you see, no break on boot here, it may be saved in a
workspace; symbols in this script are extras also).
Yet again, this script works ok with VPC but not with VMWare,
and I can not spot any difference whatsoever…
The VMWare-based target sits for some notable time, say
30 secs, probably waiting for windbg response, the port state
is reported by VMWare as “connected” (to what ???), and then
the boot continues as usual, and windbg does not see anything.
Mystery. And I thought that all named pipes are created equal:-)
I have encountered an issue with VPC that requires me to restart the
debugger whenever I restart the virtual machine.
Never ever happened to me, I run as many reboots as I want keeping
windbg running. One more mystery…
With VMWare, I have the following issue: When I boot the virtual machine
(XP), the debugger is not allowed to be started (or the VM will not boot
at all). I have to wait until after the VM has started the bootloader, I
have selected the debug flags, pressed enter, and the VM’s screen
dimensions have changed.
Can you tell me what are the VMWare’s and target’s port settings?
client/server, other end is a VM/other end is an app, yield on poll?
Speed seems not to matter (or does it?).
Anyway, I’ll try it your way, normally I start windbg way before the
target, and it’s ok for VPC.
Regards,
Alex Shvedov
----- Original Message -----
From: “Peter Scott”
To: “Kernel Debugging Interest List”
Sent: Tuesday, July 19, 2005 5:25 PM
Subject: RE: [windbg] COM <-> named pipe debugging in vmware workstation
>
> I use this method for debugging all the time. To get it working, I created
> the virtual COM port in the virtual machine to be a named pipe, as you
> did.
> Then I opened WInDbg and specified to connect via a named pipe, the only
> way
> I managed this was by running WinDbg from a command line specifying the
> following:
>
> start windbg -W Pipe -b -k com:pipe,port=\.\pipe\dbgpipe,resets=0
>
> Note that this will also break on entry into the system, I do this to
> ensure
> connectivity. It also uses the workspace profile I created called Pipe,
> which contains the symbol paths etc.
>
> I have encountered an issue with VPC that requires me to restart the
> debugger whenever I restart the virtual machine. This is not always the
> case
> with VMWare but it does happen.
>
> Pete
>
>
> Kernel Drivers
> Windows Filesystem and Device Driver Consulting
> www.KernelDrivers.com
> (303)546-0300
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@Home
> Sent: Tuesday, July 19, 2005 1:25 PM
> To: Kernel Debugging Interest List
> Subject: [windbg] COM <-> named pipe debugging in vmware workstation
>
> I successfully connect a target macine running inside VirtualPC to
> a host-based windbg through a named pipe.
>
> Now I try to do the same on a VMWare workstation 5.0.
>
> I redirect virtual’s COM1 or COM2 to \.\pipe\dbgpipe which is
> what I use for VPC but no matter what I do with other VMWare’s
> COM port settings (client vs server, app or VM on the other end,
> yield on poll), host-based windbg does not see the target
> [VMWare virtual] machine but is happy when the target runs
> inside a VPC.
>
> boot.ini’s are identical on both virtual machines, with records like
>
> multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=“win + COM1 +
> ntbtlog.txt” /fastdetect /debug /debugport=com1
> /baudrate=115200 /bootlog
>
> VMWare on-line help brought nothing new. My guess is that
> it should work, what can be possibly wrong with a named pipe?
>
> Did anyone have this problem and solved it (or did not have this
> VMWare-specific problem at all, for that matter)?
>
> Maybe, it’s some security policy setting that I’m missing?
>
> Any hints would be greatly appreciated.
>
>
> Regards,
> Alex Shvedov
>
>
>
> —
> You are currently subscribed to windbg as: xxxxx@kerneldrivers.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> You are currently subscribed to windbg as: xxxxx@bellsouth.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>