Kernel Debugging between two Windows VMs - Problems with COM

[russh]

I'm having a bit of trouble getting kernel debugging up and running between two Windows VM on a linux host.

Host: Fedora 16
VM1: Win 7 (debugger)
VM2: Win XP (target)

Since I want to remote debug XP, it looks like my only options are serial / 1394, and 1394 doesn't seem to be supported in virtualbox yet. Thus I'm trying serial. Here are the steps I've taken, with the problems arising in 6.

1. I enabled debugging for XP by adding "/debug /baudrate=115200 /debugport=COM1" to boot.ini appropriately.
2. For the VBox settings on XP VM, I enabled COM1, Host pipe, checked create pipe (thus server), and named it /tmp/com_1
3. For VBox settings on Win7 VM, I enabled COM1, Host pipe, did NOT create pipe (thus client), and used name /tmp/com_1
4. Boot XP VM in debug mode - success
5. Boot Win7 VM - success (thus it found the pipe, and indeed if we look in /tmp on linux host we see com_1 has been created)
6. Load up Windbg in Win7, select kernel debug, COM tab, baudrate=115200, port=/tmp/com_1, checked (and unchecked) pipe, tried to connect, and it cannot find path specified. I've also tried using just com1 for port name (and it shows trying to connect to \\.\com1) without any luck.

Not sure what I'm doing wrong. Pretty much all guides I can find are for Windows hosts, or use the host as the debugger an just one VM as target, etc. Anyone able to offer any advice?

[michaln]

6. Load up Windbg in Win7, select kernel debug, COM tab, baudrate=115200, port=/tmp/com_1, checked (and unchecked) pipe, tried to connect, and it cannot find path specified. I've also tried using just com1 for port name (and it shows trying to connect to \\.\com1) without any luck.

It's certain that from the guest's point of view there is no pipe, and the guest OS definitely won't see anything on /tmp/com_1. It's using a serial port, normally COM1.

My suggestion would be to ditch Linux, do this on a Windows host, and ditch the second VM because then you can run WinDbg on the host directly and connect to the VM, thus saving yourself a lot of hassle. Failing that... try some basic tests in the guests to make sure they can actually properly communicate both ways over the virtual serial "cable".

[russh]

Ditching Linux as a host isn't really an option. I've successfully done kernel debugging with a Windows host but cannot in these situations. It'll either need to be Linux or Mac host, but I believe the process should be the same between those from what I read.

The guest, or at least vbox when launching the guest, see's /tmp/com_1, otherwise the Win7 VM would never start since that hasn't been created. My understanding is we have to use this format for naming the pipe in vbox on linux/mac hosts as opposed to \\.\pipe\com_1 or similar. Before I read that in the documentation, I was also trying \\.\pipe\com_1 but of course no luck there.

[michaln]

Yes, \\.\pipe\foo only applies to Windows hosts. My point was that you have to strictly separate between what you enter on the host and what you enter in the guest.

[Waffles2g]

Hi, I know this was years ago, but did you ever manage to solve this? I am currently having the same problem.

[socratis]

1. Five years ago is a lot of time to revive a thread.
2. From "russh" details page, I don't think they're around anymore:

   Joined:       2012-04-18, 17:56
   Last visited: 2012-04-18, 22:20

It's best if you open a new thread and post complete details about your problem, than a "me too" post.