I used to debug the Windows Kernel using VirtualKD, WinDBG and a single Virtual Machine.
Recently I got a Linux machine, and now I wonder- What's the easiest way to debug the Windows Kernel when your host is unable to run VirtualKD/WinDBG*?
I assume the solution will require two Virtual Machines, but I rather have two instances hosted on my actual machine rather than having an instance residing inside another virtual instance...
Is there anyway to make that work?
Thanks in advance!
*Wine is the last resort for stability reasons...
Solved! Basically, I ended up using two (VirtualBox) VMs emulating a Serial connection (null-modem cable) over a Unix domain socket (on the host). For more info, read below:
Hardware setup*:
Debuggee:
Ensure the machine is turned off and edit Serial Ports settings.
Enable Port 1, and assign values as follows: Port Number: COM1, Port Mode: Host Pipe, Create Pipe: Unchecked (client), Port/File Path: /tmp/win_link.
Debugger:
Same as above (using the same path), only this time Create Pipe should be Checked (server).
Debugger setup:
Run WinDBG and press Ctrl+K to invoke Kernel Debugging.
in COM, enter: Baudrate: 115200, Port: COM1, Resets: 0 and verify that Pipe and Reconnect are unchecked (important).
You'll be presented with the following output: Opened \\\\.\com1 Waiting to reconnect...
Debuggee setup:
Run bootcfg /debug on /port com1 /baud 115200 /id 1. To verify, run bootcfg.**
Reboot.
Quite early during the booting stage, WinDBG on the other machine should detect the debuggee is running.
*Assuming VirtualBox is used. VMWare/KVM users will probably be able to achieve the same results following similar steps. Also, for more info refer to the VirtualBox docs.
**Assuming guests are Windows XP. Later versions include bcdedit, which may be used as described here.
For QEMU\KVM follow those instructions:
http://www.linux-kvm.org/page/WindowsGuestDrivers/GuestDebugging
Very helpful but applies to Windows XP machines. You can refer to the following link if you need to configure 2 Windows7-based virtual machines on a Linux host: http://www.aldeid.com/wiki/Category:Digital-Forensics/Computer-Forensics/Debugger/Kernel
Another option nowadays is to enable local kernel debugging. This comes with some limitations, however it will enable you to access kernel data while just using one VM.
This approach only works on Windows 8.0 and Windows Server 2012 and later.
Follow these steps:
Open a Command Prompt window as Administrator.
Enter bcdedit /debug on
If the computer is not already configured as the target of a debug transport, enter bcdedit /dbgsettings local
Reboot the computer.
Once the system is rebooted, you can execute WinDBG as Administrator, press ctrl+k or go to File -> Attach to kernel -> Local and press OK.
At that point, you will be able to execute kernel-only commands and access kernel structures:
Tested under Windows 10 and with the new WinDBG version (preview).
Reference: Setting Up Local Kernel Debugging of a Single Computer Manually
Related
I am new to virtual machines so pardon my ignorance.
I have a host machine running Windows Server 2012 R2 and I'm trying to run a VM with Windows 8.1 Enterprise using Hyper-V. I need to be able to use USB devices on the VM.
Please check screenshot for the Hyper-V settings and the VM settings. The VMConnect does not have 'Show Options' to select local resources.
I tried using Remote Desktop Connection to the VM but nothing happens when USB devices are plugged in the host machine.
Not sure what I'm missing here.
Any help in fixing this will be greatly appreciated. Thanks!
Hyper-V Settings
VM Settings
If the USB device you want to use in the VM is a USB memory stick share it with the RDP local resources option as a Drive instead of the trying to replicate the USB port itself.
Eg:
There is a dependency(XRDP) to be installed in order to enable Enhanced Session Mode. Please follow the following steps or watch this video for more clarity.
Visit https://www.youtube.com/watch?v=LS2m6iyG7_M&ab_channel=VikeshYadav
On hyper-v linux machine:
git clone https://github.com/Microsoft/linux-vm-tools
cd linux-vm-tools/ubuntu/18.04/
sudo chmod +x install.sh
sudo ./install.sh
On windows machine:
set-vm -VMName ubuntu -EnhancedSessionTransportType HvSocket
I've got Win8.1 guest system (1 gen VM) and Win10 as host. Tried pretty much everything, but wasn't able to enable Enhanced Mode (simply grayed out all the time), unless I enabled RDP connections in the guest system (Control Panel, Allow remote access to your computer). After this change VMConnect with ability to share local resources appeared on attempt to connect to the VM.
Hope this helps all the people who find this thread while googling.
Problem: vagrant up fails with the error below. I am running vagrant on Windows 7 and the base box is Ubuntu )( files.vagrantup.com/precise32.box ).
how can it be fixed?
vagrant.bat up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Clearing any previously set forwarded ports...
[default] Clearing any previously set network interfaces...
[default] Available bridged network interfaces:
1) Intel(R) PRO/1000 EB Network Connection with I/O Acceleration
2) Intel(R) PRO/1000 PL Network Connection
Vagrant is attempting to interface with the UI in a way that requires
a TTY. Most actions in Vagrant that require a TTY have configuration
switches to disable this requirement. Please do that or run Vagrant
with TTY.
Process finished with exit code 1
thanks
This worked for me on cygwin:
Or add this to ~/.bashrc:
export VAGRANT_DETECTED_OS=cygwin
Then I got the "Vagrant displays a message that it needs to run some internal upgrades..."
Edit - Oops! Spoke to soon. During its updates, I got Warning: Authentication failure. Retrying... until timeout :P
Edit 2 - I was able to fix it by setting config.ssh.private_key_path to the .vagrant.d/insecure_private_key in my Windows user's home directory.
I had the same error while destroying a Vagrant Box. I simply added -f and it did the job.
vagrant destroy m001 -f
This is happening because when script attempts vagrant destroy, Vagrant asks for [Yes/No] confirmation. Adding -f skips that.
I got the same error after upgrading Vagrant from 1.4 to 1.6.3 (Windows 7).
Running VAGRANT_HOME\bin\vagrant.exe manually resolved this issue for me:
Execute VAGRANT_HOME\bin\vagrant.exe
Vagrant displays a message that it needs to run some internal upgrades
"Press any key to continue"...
Once the process finished (it took several minutes), I was able to proceed with Vagrant instance launch as usual.
This is caused by Vagrant finding multiple Ethernet interfaces that can be used as public network and Vagrant cannot decide which one to use.
There are 3 options:
Deactivate one of the 2 adapters, so that Vagrant can use the other
Specify the Ethernet adapter you would like Vagrant to use in the vagrantfile. Like this:
app.vm.network "public_network", bridge: "Intel(R) PRO/1000 PL Network Connection"
Running the vagrant executable manually as already described in Al Belsky's answer
If you are on Windows and are starting Vagrant through MinGW (Git Bash for example) and get this message, try running it once through Windows' default cmd.exe. You are then able to answer the question about your network adapters.
I'm using Vagrant 1.7.4
Execute the below code before running vagrant up:
export VAGRANT_DETECTED_OS=cygwin
That will eliminate the exiting of vagrant and will allow you to choose Network Interface.
This may also be caused by not having Hardware Virtualization enabled in BIOS.
Also encountered this with Windows 10, when Vagrant cannot properly detect OS.
also can happen if you have both vmware and virtual box installed and you try to use MinGW.
I'm trying to do some local RDC testing using VirtualBox. The host is OSX.8, the VM is ubuntu, and VirtualBox is version 4.1.22.
The VM starts fine without any problems. I shut it down and choose "Enable Server" from the Remote Display section of the Display options and start again, and again it starts fine. Note that the port is left default and the authentication is "null".
I start Microsoft's RDC (v2.1.0) and type in 'localhost' and get: You were disconnected from the Windows-based computer because of network problems.
I try 127.0.0.1 and get the same error. Then I type in the IP of my (host) computer and get the same error. I know the loopback address avoids the firewall but I turned it off anyway and got the same error.
I get the same error whether I'm using NAT networking or bridged. What am I doing wrong?
I should note that this is a vanilla install of VirtualBox and I haven't added any extensions or guest additions or anything like that.
Seems I'm doing everything right. What am I missing? Thanks for the help!
Problem Solved! You have to install the "VirtualBox 4.1.22 Oracle VM VirtualBox Extension Pack" (available on the VB download page) to make RDC work. I wish it would tell you this when you click "enable server" but I guess that's asking too much. I hope this helps someone else.
I have the following configuration:
Host OS: Windows 7 SP1
Guest OS: Windows XP SP3 Pro
Guest OS is running inside VMWare Workstation version 7
I have configured a virtual serial port on the VM of type "output named pipe" and the following name:
\\.\pipe\whatever
I have also added the appropriate options to the boot.ini file on Win XP SP3 Pro image to allow for debugging (/debugport=com1 baudrate=115200)
in windbg, I configure the Kernel Debug option by going to:
File->Kernel Debug
and selecting the COM tab and configuring as follows:
Giving port name as:
\\.\pipe\whatever
and checking the Pipe box.
I boot up the Windows XP SP3 VM and select the second entry which has debug mode enabled. Right after I do this, I click on Ok inside the Windbg to start the kernel debugging session.
But even then it remains stuck at the following message:
Opened \.\pipe\whatever
Waiting to reconnect...
It says "Debuggee not connected" and stays at that message even after Virtual Machine boots up completely. The status of the Virtual Serial port in the VmWare also shows as Connected.
I have checked the network connections.
The VM has the Network Adapter in the Bridged Mode and I am able to ping the Guest OS and Host OS from each other successfully.
Your problem is likely to be that WinDbg isn't breaking on connect, so it's connected but it doesn't say so, and you think it's not working.
I had better luck running WinDbg from the command line with a -b, though I notice this option might have been removed in the later builds. I've tested with 6.12.0002.633 x86.
windbg -b -k com:pipe,port=\\.\pipe\com_1
(From here.)
I have had the same problem, and after changing the port at your windows guest (the one at the vmware) you should be connect. In my case the port at the boot.ini file was com1 and i have changed it to com2.
Did you also enable /debug in the boot.ini?
It could also be your VMWare serial port configuration. Config should be:
Use named pipe: \.\pipe\whatever
This end is the server.
The other end is an application.
Yield CPU on poll should be checked.
More info here:
http://www.vmware.com/support/ws5/doc/ws_devices_serial_advanced_example_debugging.html
I have Installed GTK on a Linux machine.
I am connecting To Linux Machine from a Telnet Session to compile the GTK programs
From A Windows Machine. I am using Cygwin on Windows Machine. but i am not able to see
GUI output of my GTK program on my Windows Machine.
When i run program from my terminal i get this error:
(helloworld:22576): Gtk-WARNING **: cannot open display:
I tried solutions from every answer posted, but no use now i am getting following error:
$ ./helloworld
Invalid MIT-MAGIC-COOKIE-1 key
(helloworld:22710): Gtk-WARNING **: cannot open display: 172.25.0.161:0
and i am getting following error on my Cygwin console:
client 6 rejected from IP 172.25.0.91 Auth name: MIT-MAGIC-COOKIE-1 ID: -1
You must set the DISPLAY variable in your telnet session to the IP address or DNS name of your Windows machine and append ":0"
export DISPLAY=windows.your.domain:0
And you must start an X server on the Windows machine (comes with Cygwin but you must start it).
You need to run the X window system (install with Cygwin) on your Windows-box and enable remote connections (probably with xhost). Set the DISPLAY-variable on your Linux-box to the address of your Windows-box and :0, as such:
export DISPLAY=192.168.1.123:0
I can recommend using ssh rather than telnet, for security reasons. In this case you do not need to enable remote connections with xhost, and you do not need to set the DISPLAY-variable. You only need to enable X forwarding.
You should install X-server on your windows machine and make sure you have DISPLAY set to yourmachine:0 or something like that. Or better yet use ssh instead of telnet (e.g. putty) and tunnel your X connection. You'll have to do a bit on your own research, though, because the complete answer would be a lengthy one.
Install an small X server on Windows XMing32, then run it, use putty as a console client, and check "X11 Forwarding" in Connection->SSH->X11.
Unfortunately, X11 Forwarding is not available through Telnet, you must run a SSH server on the target Linux and connect through SSH. (See if /etc/ssh/sshd_conf requires enabling X11 Forwarding too).