After getting some help from a guy at VMWare, I’ve been able to get
SoftIce working completely in the guest OS (both SVGA and VGA mode). You
first need to add these two undocumented parameters to your virtual
machine config file:
vmmouse.present = FALSE
svga.maxFullscreenRefreshTick = 5
‘maxFullscreenRefreshTick’ forces a full refresh of the screen -
lowering it improves the performance of SoftIce, but decreases
performance overall when SoftIce isn’t running.
You also should check the ‘disable mouse support’ and various mouse and
keyboard patch-disable options in the SoftIce settings, otherwise you
won’t get control of the mouse back from SoftIce (at least on my
machine).
I’ve also been able to get SoftIce remote network debugging working. You
must follow these steps in order:
- Shutdown your VM.
- Configure your VM to expose ONE virtual network adapter (the
default), and boot. - Add the SoftIce UND filter to this one adapter and shutdown again.
- Configure your VM to expose TWO virtual network adapters, and boot.
- You should now have network access as well as SoftIce network debug
support.
Don’t attach the UND while two adapters are exposed, or it will take
over both adapters and you won’t have network access (even if you ask it
to only attach to one of those adapters).
- Nicholas Ryan
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nicholas Ryan
Sent: Monday, April 07, 2003 7:38 PM
To: NT Developers Interest List
Subject: [ntdev] VMWare 4.0 and debugger compatibility (or
lack thereof)VMWare 4.0 final just went live today, and claims much
greater compatiblity with user and kernel-mode debuggers. I
ventured to test this claim.Verdict? Not as good as I hoped. They’ve fixed the
long-standing incompatibility between VMWare and SoftIce on
the HOST machine, but SoftIce does not work in any shape or
form on the GUEST machine (a step BACKWARDS from previous
versions, which supported at least VGA mode). I can produce
nothing more than a machine lockup when the debugger is invoked.Furthermore, WinDbg doesn’t work as advertised when used to
debug the guest. The method described in the VMWare User
Guide (and in some old threads on Usenet) that describes
configuring VMWare to hook a serial port to a pipe on the
guest, then hook WinDbg to the pipe on the host (using an
undocumented WinDbg command) simply doesn’t work. WinDbg
won’t connect on break, even though the target machine locks
up as if WinDbg had full control.The only way I could get WinDbg to work was to download a
program called ‘VSPD XP3’ from Eltima Software that simulates
a software loopback between two virtual serial ports (that
appear to everyone else as hardware COM devices). WinDbg and
the guest were able to communicate through this wormhole
perfectly well, except now WinDbg crawls along at typical
serial port speeds instead of the much higher speeds I’m led
to believe the pipe method is able to support.I’d appreciate it if somebody else (Maxim especially, he had
a post on Usenet back in the fall regarding the settings he
used to get earlier versions of the two software packages
talking) can try to get WinDbg working better than I did.
(VMWare 4.0 has an eval download).My setup is this: Windows XP Pro SP1 (both host and guest),
Dell Latitude D600 Pentium M 1.6 ghz, 512 megs memory (soon
to be 1 gig) split about evenly, VMWare 4.0, WinDbg 6.1.17.2,
SoftIce 2.7.(And before you say it’s the Pentium M’s fault, I tried this
on a plain-Jane desktop Pentium 4 with equally dismal results).My boot.ini options on the guest were this:
/fastdetect /debug /debugport=COM1 /baudrate=38400 (selection
of baudrate didn’t matter)The VMWare serial port was configured thus:
- Use named pipe
- \.\pipe\windbg
- This end is the server
- The other end is an application
My WinDbg command-line was this:
“” -QY -v -k com:port=\.\pipe\windbg,pipe
>
> - Nicholas Ryan
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@nryan.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>