How can I debug Windows in one virtual machine from another virtual machine using VirtualBox?

I am working on some pre-logon code for Windows 7 and would like to be able to debug it (at least to see how it works, since the Microsoft documentation is terrible).

My environment is VirtualBox on a Linux host with three Windows virtual machines (Windows 2008 domain controller, Windows 7 dev machine and Windows 7 test machine), and I would like to be able to debug the process of starting the test machine remotely from the development machine using a virtual serial connection of two virtual machines.

[I have in another life debugged Linux kernel drivers in one Linux machine from another that uses a VMware workstation on a Windows host, so I know that such a thing is potentially possible.]

I saw people using windbg to debug Windows in a virtual virtual machine from the host, but I need to do this from the second guest (because my host is not Windows). Has anyone figured out how to do this?

Edit: Before I sent the message, I tried to make an obvious approach. I created a virtual serial port in each configuration of the virtual machine and linked them to the same hosting, which must be created by dev VM (debugger) and used by test VM (debugee). Then i ran

bcdedit /dbgsettings serial debugport:1 baudrate:115200 bcdedit /debug {current} on 

in the test VM and turn it off. Ran windbg in dev VM chose kernel debugging (on the correct serial port) and restarted the test virtual machine. There were some reports that they did not have characters available, and the test VM was hanging.

Since then I found this article: http://www.benjaminhumphrey.co.uk/remote-kernel-debugging-windbg-virtualbox/ , which (although this guy uses a Windows host) seems to accurately describe the method I'd tried but his test VM does not hang. The result that I get in the wndbg window is the same as it’s, but it stops before the line looks "Windows XP kernel ..."

Now I'm not sure if this problem is related to VirtualBox and is more unsure whether I am using windbg correctly. Any help would be appreciated.

Other Editing . I tried to connect the virtual serial port of the test virtual machine to the host file, and I received some debug output in the file. I tried installing the virtual serial ports of the two virtual machines to point to the host channel and run the terminal (and not WinDbg) in the Dev VM, and I get debugging information in the terminal.

I think that now I decided that this is definitely a problem with WinDbg and not with VirtualBox (I will remove the virtualbox tag and replace it with windbg), but I'm not sure why WinDbg is not talking.

Additional Information: I just updated the Update to VirtualBox 4.2.4 (not sure if the version matters) and looked at it again.

I rebuilt the test virtual machine and became more patient!

Now it seems that the test VM is working - and in the end I get some result in the windbg window, but it takes about 15 minutes to start the debuggee OS! This is clearly not useful for daily kernel debugging. I have no idea why this should be so slow ... there is no noticeable slowdown if I run a simple terminal in dev VM instead of windbg (although, of course, debugging information is mostly garbage).

Any ideas?

+4
source share
1 answer

I understand that this is one helluva-necro, but ...

Have you tried setting up debugee for network debugging in kernel mode? I think the slowdown is largely due to the fact that the series is so gd slow.

http://msdn.microsoft.com/en-us/library/windows/hardware/hh439346%28v=vs.85%29.aspx

If / when M $ decides to hide this link, these parts of the above article are what you need to do to configure this setting:

Setting up the target computer

To configure the target computer, follow these steps:

 Verify that the target computer has a supported network adapter. Connect the supported adapter to a network hub or switch using standard CAT5 or better network cable. Do not use a crossover cable, and do not use a crossover port in your hub or switch. In an elevated Command Prompt window, enter the following commands, where wxyz is the IP address of the host computer, and n is a port number of your choice: bcdedit /debug on bcdedit /dbgsettings net hostip:wxyz port:n bcdedit will display an automatically generated key. Copy the key and store it on a removable storage device like a USB flash drive. You will need the key when you start a debugging session on the host computer. Note We strongly recommend that you use an automatically generated key. However, you can create your own key as described later in the Creating Your Own Key section. If there is more than one network adapter in the target computer, use Device Manager to determine the PCI bus, device, and function numbers for the adapter you want to use for debugging. Then in an elevated Command Prompt window, enter the following command, where b, d, and f are the bus number, device number, and function number of the adapter: bcdedit /set "{dbgsettings}" busparams bdf Reboot the target computer. 

And to connect to it, follow these steps:

 Using WinDbg On the host computer, open WinDbg. On the File menu, choose Kernel Debug. In the Kernel Debugging dialog box, open the Net tab. Enter your port number and key. Click OK. You can also start a session with WinDbg by opening a Command Prompt window and entering the following command, where n is your port number and Key is the key that was automatically generated by bcdedit when you set up the target computer: windbg -k net:port=n,key=Key If you are prompted about allowing WinDbg to access the port through the firewall, allow WinDbg to access the port for all the different network types. Using KD On the host computer, open a Command Prompt window. Enter the following command, where n is your port number and Key is the key that was automatically generated by bcdedit when you set up the target computer: kd -k net:port=n,key=Key If you are prompted about allowing KD to access the port through the firewall, allow KD to access the port for all the different network types. 
0
source

Source: https://habr.com/ru/post/1436579/


All Articles