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.
Related
I am trying to find all the functions including both user mode functions and kernel mode functions that wmic.exe calls to execute the diskdrive command. In order to do this I opened wmic.exe in my virtual machine and set breakpoint in kernel mode windbg on WMIC!CParsedInfo::GetUser and WMIC!CExecEngine::ExecuteCommand.
As soon as I input diskdrive debugger breaks on ExecuteCommand, I am in kernel mode through COM port, but I cant use wt command, however I can run instructions line by line and step in to every call and track all function in stack call, but this will take lots of time and it’s not optimized. Is there any way to do something similar to the wt command in the kernel debugger?
Whenever I use the wt command it outputs ^ Unimplemented error in 'wt'.
Some extra info:
I am running Windows 11 Enterprise Build 22000.856 on VMWare and connected to it through the COM port for kernel debugging and the host OS is the latest version of Windows 11 Enterprise.
Windbg is also the latest version of windbg.
Both windbg and vmware running as administrator.
I am able to use all the usual commands I can see registers, see stack calls with single step, see threads and etc.
wt runs normally on my main OS for user mode processes on my main OS without any problem
I am making a driver for windows kernel and I am using COM1 for getting log of kernel, the host machine is Ubuntu and guest is qemu. Windows 10 is installed inside it. The problem is there is a bulk of data to be write on COM1. So if it has to write a line ABCDEFGHI and in the next line, it has to write JKLMNOPQ.. it is doing something like ABCDEF in one line and GHIJKLMNOPQ in the second line, means one line data is incomplete and 2nd line data is also corrupting due to this.. is there any lock we can apply? that if one connection is using COM1 then no any other should write on COM1?
QEMU does not control who can write to serial port address at certain time. It's the guest OS's job. QEMU just receives whatever data it sees in the virtual registers.
If you really need to write bulk data to the serial port in the guest OS, you would expect very long time of process. I ever had the same problem and had to test the speed on a very fast Intel CPU. The best speed I can get is 220KBps.
If processing time is not a problem for you, from guest Windows perspective, if you directly write to COM1's port address, it's your driver's responsibility to make locking mechanism, assuming there is no other drivers/processes writing to COM1 either. If you write data via a handle to the COM1 device, there is no locking provided directly by Windows built-in serial port driver. But you still can do it in other ways: open a handle to the serial port device exclusively, so only one process can write to it, or make a device filter driver sitting above Windows serial port driver to add this additional access control, or even directly modify Windows serial port driver's source code to add what you want. Its source code is available now on github.
If none of above applies to your case, you might want to double check how you capture the output of COM1 on host, usually redirected to files, shell and etc. They also could cause some mystery of troubles.
Win32API environment.
I need to identify which program is using a particular serial COM port. For example, if putty has opened COM4 and I later try to start another program that also wants to open COM4, how can I discover that putty is the program preventing this?
In other words, assuming I already have a list of all ports installed on the system, how do I work backwards to discover which programs have opened which ports?
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.