I'm following this article https://msdn.microsoft.com/en-us/library/windows/hardware/mt269367(v=vs.85).aspx and I've gotten to the step where you run the command to start WinDbg.
WinDbg –k net:port=50000,key=1.2.3.4
However, when WinDbg restarts it is stuck on "Waiting to reconnect..." and it shows "Debugee not connected" at the bottom. I've tried unplugging the Ethernet cable multiple times as well as restarting the target multiple times. I can also ping the host computer from the target. Oddly, I can't ping the target from the host.
The host machine is running Windows 7 and the target machine is Windows 8.
So I turned off the firewall on the host and it started to work.
Related
I face a problem that I can ping to correct IP address, it have no loss. And also I use nmap ping the pi address, and I get it correctly. Then I using VNC viewer to try access to pi, but it always show up "The connection was refused by the host computer"
Did u all have any idea ?
Your problem indicates that your Raspberry Pi was reached by the connection attempt, but that no service was running on the relevant port and hence the connection was refused. I think, this is because the VNC service is not running on your Raspberry Pi.
Update 1
Raspbian now comes with the server by default thanks to a partnership with RealVNC, it just needs to be enabled.
Original
You must enable VNC Server on your Raspberry Pi using terminal
sudo apt-get update
sudo apt-get install realvnc-vnc-server
or you can also enable VNC Server on the command line using the sudo raspi-config command.
Advanced Options->VNC:Yes
Now you can connect to the VNC Server using a application such as VNC Viewer.
I have been having this issue with my Raspberry Pi Zero W even though it worked perfectly beforehand. This page https://www.realvnc.com/en/connect/docs/raspberry-pi.html should help.
I ran vncserver in a ssh window after verifying the interface settings in raspi-config.
It started the VNC Server and gave me the VNC Server catchphrase and the IP address with Port Number as shown in the photo linked below.
vncserver output
After running that command I was able to get the VNC Viewer on my windows machine to connect to the pi.
I then ran sudo systemctl enable vncserver-x11-serviced.service in the ssh window so that it would start automatically on subsequent reboots.
I've had this same problem but found a different reason. I found three ways to get around this error message.
Plug a mouse or keyboard into the Raspberry Pi zero, waking up the screen and the VNC connection.
Wait about 5 - 10 minutes which is the amount of time for the screen saver to kick in which seems to wake up VNC connection. but don't wait to long other wise run this command to get things going via ssh "systemctl start vncserver-x11-serviced.service".
I am hoping the new update they just published will fix this problem. I don't see this as much with the Raspi B3+ as with the Zero H.
The last was plug in both monitor and mouse and that for sure fixes the VNC issues but defeats the headless connection. It seems that running headless and the screen/saver are somehow related but just not smart enough to figure it out.
For people using newer version of Raspberry, VNC option is found under:
Config>Interface Options
pinging to any service will only tells us that whether the server is currently listening on that port or not. It will not tell you the possible result to connection request asked by client.
It seems that, you have installed VNC server but not started it properly. Use this command to start it...
# vncserver start
Also recheck the port number is correct or not.
With the Rasp Pi 4 - had connecting fail after rebooting both the server and client (both Rasp Pi 4s).
Took a while to realize that I have two clients: One named "VNC Client", the other "VNC Viewer for Google Chrome".
The former works, the latter doesn't.
I have just recently installed Genymotion and VirtualBox on Solus and when I start a virtual device y I get this error:
The connection to the virtual device has been lost.
Please restart the virtual device.
When I start the machine the screen loads but it's all in black and then I get that error.
I googled that and I found that I must reconfigure de Host-only network adapter but unfortunatly it didn't resolve the problem.
I also tried reinstalling virtualbox and genymotion but it didn't solve the problem.
Here's my log file: http://pastebin.com/CsdCJAw3 (I posted it in pastebin because it exceeds the characters limit here)
Thanks in advance
Are you running a VPN client like Cisco Any Connect. I was running it and Genymotion was continuously showing me the same issue. I just had to stop the VPN and close the VPN app if any.
Restart Genymotion and voila it connected.
You can start your VPN after that and it should work.
In case it still doesn't work. After stopping the VPN or if you're not running the VPN client before starting Genymotion try running this command.
This used to help me when something was causing an issue with the virtual box daemon.
sudo /Library/Application\ Support/VirtualBox/LaunchDaemons/VirtualBoxStartup.sh restart
I'm trying to Kernel Debug Raspberry PI3 using Bus Pirate, I've followed the instructions to connect them, and also the steps from
(https://developer.microsoft.com/en-us/windows/iot/docs/Windbg.htm)
However everytime I run the following command
windbg.exe -k com:port=com3,baud=921600
but once I restart I get "waiting to reconnect..." and nothing happens?
Any advice, have you come across this problem? My target is a PI3 and using the latest, 10.0.14393.693 version of Win 10 IoT Core.
Solved this by running the following on Raspberry PI
bcdedit /dbgsettings serial debugport:1 baudrate:115200
On the Host machine running the baudrate of the following
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86>windbg.exe -k com:port=COM3,baud=921600
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
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