The Target Machine has Windows 8.1 installed, Host Machine has Windows 7 installed (but the Host OS has nothing to do with connection error). I'm using the Debugger of the Windows 8.1 SDK package.
Settings on Target Machine
bcdedit /debug on
bdcedit /dbgsettings net hostip:xx.xx.xx.xx port:xxxxx
bcdedit /set {dbgsettings} busparams x.y.z
After that, I rebooted the Target Machine.
Error Log
The transport connection between host kernel debugger and target windows seems lost. Please try resync with the target, recycle the host debugger or reboot the target windows.
... Retry sending the same data packet for 10884 times.
... Retry sending the same data packet for 10997 times.
>>>>**WinSock write error. Error 0n10040**
>>>>WriteAll(0x00002738,0x00000003,1304,0) fails.
>>>>WritePacketContents failed. Status == 0x2738
I also looked at above Error code meaning
10040 WSAEMSGSIZE Message too long
A message sent on a datagram socket was larger than the internal message buffer or some other
network limit, or the buffer used to receive a datagram was smaller
than the datagram itself.
but I'm not sure how to fix it.
Related
I have a custom windows kernel driver I have compiled. I sign it with a test cert, create the cat file from the cdf, stamp the inx into a inf file, then load it with pnputil. I then create a software device with SwDeviceCreate so the OS will pair my driver and the driver. This works fine.
The problem is if i screw up something in the compilation and get something like an error code 39 (viewable in device manager), I do not see that error. Instead the OS seems to try to fix the error by loading the previously working version of the driver. In order to see that error, I have to purge the driver and device using pnputil /d oem42.inf along with a pnputil /remove-device, then restart my PC, that seems to fix the issue. This is difficult because it means i have to restart my PC every time i run a test. I know crashing a kernel driver can cause a panic anyway and cause me to restart, but there seems to be instances where this is not the case and the OS tries to rectify the issue without me (as it probably should).
So my question is this. Is there a way to completely purge my driver without a complete restart in-between installations/tests so I can correctly break it. I know I am suppose to use another machine and remote debug kernel drivers, but i do not have access to another machine right now that can support windows 11.
I am using windbg to begin a kernel debug with a vmware windows machine. I referred to
https://msdn.microsoft.com/en-us/library/windows/hardware/ff538143(v=vs.85).aspx.
But I didn't succeed. I had two question about it.
1). After I start windbg by such a command:
**windbg -k com:port=\\10.57.43.22\pipe\debug,pipe**
It will show:
**Fail to open \\10.57.43.22\pipe\debug
Kernel debugger failed initialization, Win32 error On1326
"Logon failure: unknown user name or bad password"**
What is the reason? There is no space for me to type user name or password.
2). In the msdn article, it said :
In the virtual machine, configure the COM port to map to a named pipe.
I had added a serial port which used a named pipe on vmware virtual machine. How to map a COM port to a pipe?
Serial and network debugging are two different things.
To debug a VMWARE virtual machine, once you have added the COM port to the VM, then in the VM settings:
Notice:
The name of the named pipe is \\.\pipe\com_port (you can use whatever you want after \\.\pipe\)
The COM port number is 2 (see in the picture where it is mentioned "Serial Port 2" on the left pane)
The two dropboxes with this end is the server and the other end is an application.
According to the documentation, about "Yield CPU on Poll":
This configuration option forces the affected virtual machine to yield
processor time if the only task it is trying to do is poll the virtual
serial port.
Don't forget to configure the Windows VM with bcdedit:
bcdedit /debug on
bcdedit /dbgsettings serial debugport:2 baudrate:115200
Restart your VM once this is done. In this case I use the serial port 2 (usually, the first COM port in VMWARE is used by the printer).
Start Windbg with a command line like this:
windbg -k com:pipe,port=\\.\pipe\com_port,resets=0,reconnect
Or, once on Windbg, use CTRL+K, then:
You should be able to kernel debug your VM.
I tried to use KGDB on Ubuntu 14.04.2 - 3.16 kernel.
Target is running with 3.16 kernel on Ubuntu 14.04.2.
Host is running with 3.16 kernel on Ububtu 14.04.2.
Target is waiting for remote gdb connection.
Started my Host mechine and try to connect target..
$ gdb ./vmlinux
kernel image file of target machine.
$ gdb> target remote /dev/ttyS0
“unrecognized item timeout in qsupported response”.
Not able to proceed further. Can any one pass some lite on this?
The “unrecognized item timeout in qsupported response” error message most typically occurs when the serial connection between the debug station (GDB host) and target (SUT) is not running reliably in my experience. The usual solution is to do two things. FIRST, check the serial connection manually using a program such as minicom, setserial, and sty. (Check your baud rate match, and that characters appear to transfer between the two systems OK manually). Unfortunately, in my experience, the even with the correct RTS/CTS hardware flow control dongles interspersed, the KDBG agent on the target doesn't handle flow control well. So the manual test will appear to work (no real flow control with a manual test, but it does prove you have correct baud rate control on both ends and complete control). SECOND, and the typically required best solution in my experience is to lower the baud rate down to 9600. (Everyone starts at MAX, or 57600, or 34K, or 19200), but drop it to down to 9600. The data sent/received by the kernel debugger is small, and even the serial console doesn't generate a lot of data in debug situations. By locking the baud rate down to 9600, you wake sure the SUT serial kgdboc keeps up on the target, and the problem you are seeing usually goes away. If you find the speed too slow, once you have it running properly at 9600, then you can increase the speed back up one step at a time (on both ends) and find the maximum serial rate for your setup that works properly.
I don't know where i make a mistake. I try to connect mi host pc (Windows 7) to target pc (virtual machine with Windows 7) in order to start with remote kernel debugging.
Vmware (virtual machine) serial port settings:
Windgb kernel debugging:
Boot virtual machine settings:
If I turn on or turn off virtual machine, nothing happens..
Does anyone know what I'm doing wrong? By the way, is it possible to view content of variables in a driver using LiveKd?
I changed debug port to 2 and host machine can connect to target machine, but windbg get error message "Assertion failed: Missing StreamContext Support ..." and VM hangs at the "Starting Windows" and nothing more happens..
Those settings look correct to me. Occasionally when I see the same behavior I just tell WinDbg to "Break" and that appears to finish the connection.
I've been struggling with much the same thing. It's been a while since I've spent much time kernel debugging with Windbg. I run Linux for pretty much everything, so this time I tried using two KVM/QEMU VM's managed by Libvirt. Lots of different complexity there, since the version of Libvirt I'm using doesn't provide easy "ui" methods of connecting serial ports between VMs (Libvirt hint: the XML setup for the serial ports, one system's Serial port source type must be set to "bind" and one system set to "connect", even for serial type "unix")
Finally, I was able to use Putty on both VM's and chat back and forth, confirming the COM ports I've chosen are indeed connected.
... and still Windbg on my debug host continued to say "Waiting to connect..."
Just confirming #jcopenha's answer, sending Break did just work for me (I don't have Break on my laptop kbd, so I used the Debug Menu to choose "Break").
The Target system is frozen (yes, after the target was fully booted, which was another question I couldn't remember the answer to), and !process gives me interesting info from the target system. I would Up-Vote their answer, but I am new to StackOverflow and don't have the reputation yet.
Thank you!
I am new to driver stuff. I have tried to debug the kernel driver using serial COM port without success. Could someone show me proper direction how to fix the problem?
I am seeing the following messages on kd console.
ERROR: DavReadRegistryValues/RegQueryValueExW(4). WStatus = 127
ERROR: DavReadRegistryValues/RegQueryValueExW(5). WStatus = 127
ERROR: DavReadRegistryValues/RegQueryValueExW(6). WStatus = 127
At this time, I pressed Ctl^D and kd console and I am seeing
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
EDIT: The problem is fixed with WinDbg. I changed the baud rate to 115200 and inserted break (Ctr ^ Break) before Target system completely boots up. I am able to debug the code now. If I insert break after the target system completely boots up then I am unable to debug. I don't know exact reason for it but Happy with current situation.
Here are the things I have done
1) Prepared Target system for debug mode by editing the boot.ini file. Added “/debugport=com1 /baudrate=57600” to boot.ini
2) On Host system, started kd.exe and seeing the following output
C:\Program Files\Debugging Tools for Windows>kd.exe -k com:port=1,baud=57600
Microsoft (R) Windows Debugger Version 6.6.0007.5
Copyright (c) Microsoft Corporation. All rights reserved.
Opened \\.\com1
Waiting to reconnect...
3) Rebooted Target system, system boots slowly than normal boot and I am seeing some messages <<below>> on Host system console
4) At this time, If I press Ctl-C on KD console then Target system freezes (hangs) and proceeds if I enter "g" at kd prompt. This means that Target system is going to debug mode
5) However After some time I am seeing the following message on the host machine console
ERROR: DavReadRegistryValues/RegQueryValueExW(4). WStatus = 127
ERROR: DavReadRegistryValues/RegQueryValueExW(5). WStatus = 127
ERROR: DavReadRegistryValues/RegQueryValueExW(6). WStatus = 127
After the above message there are no messages appearing on kd console.
I searched internet for "ERROR: DavReadRegistryValues/RegQueryValueExW(6). WStatus = 127" but didn't get proper reason for it.
I pressed Ctl^D and kd console and I am seeing
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
READ: Wait for type 7 packet
READ: Timeout.
I have tried above steps with following options ..but no luck
I disabled firewall & antivirus software on both Host and Target systems.
I unplugged and re-plugged serial cable connection between each trail
I have logged-in with Domain account local account with Admin rights
Can someone show some light on how to proceed? Both systems are running on XP 32bit SP3 OS.
Thanks
King
Are you sure you have a good serial connection?
The cable must be a null modem cable - you should verify this using a terminal program (without kernel debugging enabled on the target). Run the program (HyperTerminal or whatever) on both the target and the host machines (remember, like I said before kernel debugging over that port must not be enabled on the target or the port can't be opened).
You can find some links to free terminal programs (I don't think Microsoft provides HyperTerminal anymore since Vista) here: http://www.lvr.com/serport.htm#software
Type some characters on one machine, and make sure they show up on the other side. Do the same on the other machine.
If you can't do this, then there's no serial connection and you'll have to get a null modem cable or adapter. There's no point in trying to get KD to work over that connection until you can do this.
Also, remember that the COM port used by kernel debugging on the target must be a standard 8250 family UART (usually a 16550 or better nowadays, and usually baked into the motherboard chipset). It can't be a USB serial port connector (although that kind will work fine on the host side, since on the host kd.exe is a regular Win32 program).
Edit:
If it's not a serial connection problem, the problem might be that your target doesn't support configuration using boot.ini. Since Vista, boot parameters have been specified using the "Boot Configuration Database" (BCD) which is manipulated with a program like bcdedit.exe. Unfortunately, configuring a system using BCDedit is much more complicated than just editing a simple text file like boot.ini.
You should read the debugger helpfile section "Configuring Software on the Target Computer"; in particular the "Using Boot Parameters" part. there are details there on how bcdedit can be used to enable debugging on Vista and later systems.
The other thing you can test to see if debugging is working on the target is to invoke kd -kl on the target - if it tells you debugging isn't enabled, you haven't set up boot.ini correctly.