My setup is: Windows 7 host system, VirtualBox/Windows 8 32-bit target system (debugee), host-only network to connect the two. Starting with Windows 8 it's declared possible to setup kernel debugging over network --- seems to be a nice option in this case. So I verified that the NIC is supported (http://msdn.microsoft.com/en-us/library/windows/hardware/hh830880 --- Intel 822540 DevID 100E is included on the list) and followed instructions in http://msdn.microsoft.com/en-us/library/windows/hardware/hh439346(v=vs.85).aspx. Not successfull, windbg says: debuggee not connected, can't break the target system. (There is some communication since windbg detects target system restart.)
So the question is: has anyone tried this? Succeeded? Anything important that I miss? Should I resort to configure a serial connection or perhaps install VirtualKD?
Related
I'm trying to kernel debug a physical Macbook pro device.
When my setup contains a VM, between a host MacOS and guest MacOS, its working with no problem using lldb -o "kdp-remote <guest_machine_ip>"
my boot-args on my remote (to debug) Macbook are:
user$ nvram boot-args
boot-args debug=0x44 kext-dev-mode=1 pmuflags=1 -v kcsuffix=debug
When i'm triggering kernel debug using either
sudo dtrace -w -n "BEGIN { breakpoint(); }"
or LEFT CMD + RIGHT CMD + PowerButton, the system is in halt mode, not responsive to anything (Mouse not moving, etc)
But when I'm trying to connect to the machine from the host using the lldb command provided earlier, it's not working.
I've made sure the machines can ping each other and I can set up a SSH connection.
To the best of my understanding, I had to user special Apple adapters (Real™ Ethernet adapter), so I'm using the following adapters to debug the remote machine:
https://www.apple.com/shop/product/MMEL2AM/A/thunderbolt-3-usb-c-to-thunderbolt-2-adapter
https://www.apple.com/shop/product/MD463LL/A/thunderbolt-to-gigabit-ethernet-adapter
The physical connections setup looks like that:
MacOS-Debugger --(USBC to Ethernet adapter)--> Ethernet cable <-- (ThunderBolt to Ethernet adapter) <-- (ThunderBolt3 to ThunderBolt2 adapter) <-- MacOS-debuggee
Generally for the debugging I used the following tutorial, which worked for VM debugging:
https://knight.sc/debugging/2018/08/15/macos-kernel-debugging.html, I didn't find the exact KDK version, but I don't think it should be the problem here
My debugger is BigSur, and my debugee is Catalina
Any ideas to what the problem may be will be helpful
Your hardware setup sounds fine. Note that you don't necessarily need a direct ethernet cable connection, you can use your normal office-/home-wide wired network, it's fine to have a switch (or even more than one) between debugger and target. The debugger machine can even be using wifi as long as it can reach the target's wired network connection that way, though it's not recommended. The Thunderbolt Ethernet interface need not be Apple branded, but its driver does need to include kernel debugging support. In practice, for example, I've successfully used the Ethernet port in a OWC brand Thunderbolt Dock as well. Using one of Apple's own adapters of course guarantees it will work.
If the boot-args on your target machine are the same as what you used in the VM, that's probably where your problem is coming from. You should specify the device to be used for kernel debugging, using the kdp_match_name= option. Use the ifconfig command in the Terminal to work out which of the listed devices is your Thunderbolt ethernet adapter (enX), possibly based on the IP address. en0 is typically wifi in Mac laptops, so you're usually looking for X > 0.
So you'll end up with something like kdp_match_name=en1 added to your boot-args. Make sure to reboot the machine cleanly before attempting a debugging session after updating the boot-args setting.
A few more comments:
kext-dev-mode=1
This option no longer has any effect. It only existed in OS X 10.10. You can remove it.
I didn't find the exact KDK version, but I don't think it should be the problem here
Having a KDK version that doesn't match the target's exact kernel binary UUID will not prevent a connection, but it will prevent you from doing any meaningful debugging as the memory layout of threads etc. will not be available.
My debugger is Big Sur, and my debuggee is Catalina
If you ever run Big Sur on your target, make sure to add wdt=-1 to your boot-args or the hung/crashed machine will reboot before you get a chance to connect with the debugger.
I have a problem with connection network for internet.
The host is Windows 10 x64 and the guest in VMware is MacPro Yosemite for AMD
My config
Windows 10
Processor AMD
Network card Realtek GBE Family Controller
VMworkstation PRO and Player 12
OS X Niresh Yosemite for AMD
The mac operating properly. No problem during normal use. Unfortunately unable to connect to a network.
I try several solutions found on google.
I think of two possibilities.
The first is a bad network connection at my Windows with VMware Network Adapter. I do not know if it's VMnet 1 or VMnet 8 should be used. Then when I share or I make a bridge with these connections, VMware Network Adapter detects no internet connection. (See , and )
The second would be that I do not have good drivers, I try to install with MultiBeast - Yosemit Edition, nothing happens, I just got this device in existing connection (see )
I also tried installing the driver with KextBeast http://www.insanelymac.com/forum/topic/287161-new-driver-for-realtek-rtl8111/
I also discovered that the mac does not detect network card, is this correct? (see )
I try on my two VM, the result is the same. I think I'm doing something wrong
Ok for me the solution after multiple test on terminal with kext file etc...
From niresh, again
http://www.hackintosh.zone/file/118-all-in-one-network-solution-wireless-ethernet/
I am working on this example on writing a simple Windows driver and debugging it from VS:
https://msdn.microsoft.com/en-us/library/windows/hardware/hh439665(v=vs.85).aspx
My Setup
Host: Windows 7 Physical system
Target: Windows 7 Physical system
Connection type: Serial cable (USB to serial in host, serial in
target)
Provisioning the target system is successful. Serial connection parameters are correct (tested the serial connection with different software). Driver is built and installed successfully in the target but "Break all" command does nothing. I am able to attach to a different process in the target.
I have seen similar questions and the usual response is to check for a mismatch between the connection parameters in the host and the target. I have checked this and the parameters are correct.
I would appreciate any advice.
Thanks!
Host: Windows 7 x64
Guest: Windows XP SP3 x86
I got 2 PCI firewire cards on both ends (SIIG 1394 installed as Texas Instruments OHCI Compliant IEEE 1394 Host Controller).
On Windows XP I added the following to boot.ini:
/debug /debugport=1394 /channel=10
I rebooted Windows XP and OHCI driver got yellow banged (which is expected).
On Windows 7 (host) I run WinDBG(x86), open kernel debug, 1394, specify channel 10 and run
It says:
Using 1394 for debugging
Checking 1394 debug driver version.
Opened \.\DBG1394_INSTANCE10
Timer Resolution set to 1000 usec.
Waiting to reconnect...
Nothing happens. (1394 Windows Kernel mode driver is installed).
On each firewire card I got 3 ports, but I am not sure whether it matter which one needs to be used.
Please advise what might be wrong in the configuration above.
How can test 1394 connection independently ?
I had no multiple OHCI controllers on either end.
Finally, by simply exchanging components one by one, I have identified that the issue was caused by malfunctioning Firewire cable. It was not visually damaged, but it looked like it was accidentally used for something else except Firewire ports.
Unfortunately, it took time to identify the root cause since Microsoft doesn't provide any utility to ensure physical connection between both machines.
I have a really strange problem with WinDbg and would like to know if anyone can explain to me why it happens.
So here is the setup:
Debugging a target Windows 7 64bit machine with WinDbg
Host machine running Windows 7 64bit also
Host and Test machines connected via firewire
Host and Test machines connected to the same switch (a Netgear gigabit switch, 8 port)
Break into the test machine
Problem: After about 10 seconds the host machine loses network connection
What resolves the problem immediately:
Run on test machine (Go)
Unplugging the test machine's Ethernet cable
Does anyone know why this happens, and if there are solutions?
Try disabling Flow Control on the network adapter of your target machine (generally there is an option in the Device Manager settings for the device). If you don't have a specific flow control option (or even if you do), also set the network adapter to Half Duplex mode.