[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 00/43] Windbg supporting

From: Mihail Abakumov
Subject: Re: [Qemu-devel] [PATCH v2 00/43] Windbg supporting
Date: Wed, 08 Nov 2017 17:28:06 +0300
User-agent: Roundcube Webmail/1.1.2

Ladi Prosek писал 2017-11-08 16:43:
On Wed, Nov 8, 2017 at 12:54 PM, Mihail Abakumov
<address@hidden> wrote:
Ladi Prosek писал 2017-11-06 18:15:

On Mon, Oct 23, 2017 at 10:31 AM, Ladi Prosek <address@hidden> wrote:

On Tue, Oct 17, 2017 at 3:08 PM, Mihail Abakumov
<address@hidden> wrote:

An update of:


We made the debugger module WinDbg (like GDB) for QEMU. This is the
replacement of the remote stub in Windows kernel. Used for remote Windows
kernel debugging without debugging mode.

WinDbg is a multipurpose debugger for the Microsoft Windows computer operating system, distributed by Microsoft. Recent versions of WinDbg have been and are being distributed as part of the free Debugging Tools for
Windows suite.

How to start debugging QEMU using WinDbg:
  Run QEMU with next option:
    -windbg pipe:<name>
  QEMU will start and pause for waiting WinDbg connection.
  Run WinDbg with next options:
    -b -k com:pipe,baud=115200,port=\\.\pipe\<name>,resets=0
  Wait for debugger connect to kernel.

Note: You can add Symbol Search Path in WinDbg such as

How it works:
The WinDbg debugger has the possibility of connecting to a remote debug service (Kdsrv.exe) in the Windows kernel. Therefore, it is possible to connect to the guest system running in the QEMU emulator. Kernel debugging is possible only with the enabled debugging mode, may change at the same time. Our module of WinDbg debugger for QEMU is an alternative of the remote
debugging service in the kernel. Thus, the debugger connects to the
debugging module, not to the kernel of the operating system. The module obtains all the necessary information answering debugger requests from the QEMU emulator. At the same time for debugging there is no need to enable debugging mode in the kernel. This leads to hidden debugging. Our module
supports all features of WinDbg regarding remote debugging, besides
interception of events and exceptions. Only i386 is supported now.

Changed in v2:

 - Move target specific code in the 'target/' directory. (Alistair
- Change 'kd_api_fill_memory'. Made a fill of memory by line segments. Before that, a full array was immediately collected and written in RAM.
(Ladi Prosek)
 - Change 'kd_api_search_memory'. Made a search for memory by line
segments. (Ladi Prosek)
 - Change ld* to st* where it needs. (Ladi Prosek)
- Add a additional check of input arguments in 'windbg_read_context'
and 'windbg_read_ks_regs'. (Ladi Prosek)
 - Fix typos. (Ladi Prosek)
 - Add a fliping back 'windbg_state->is_loaded' after reset VM.
 - Add a check to disabled kvm. It is supported yet. (Ladi Prosek)
- Add a check to device in windbg option. Only pipe is supporting now.
(Alistair Francis)
- Add a check to 'ifdef' WINDBG_DEBUG_ON before define it. (Alistair
 - Replace printf to qemu_log. (Alistair Francis)
 - Fix build on s390x host. (patchew)
 - Fix code style error. (patchew)

Thank you, I am planning to take a closer look and test the changes in
a week or two.

Still wondering if it is limited to Windows hosts or if it can be used
on Linux as well, preferably with KVM.

I haven't been able to make this work.

I've built a 32-bit QEMU for Windows with these patches and used the
command line parameters given above:

  qemu-system-i386.exe run with -windbg pipe:win7_dbg
  windbg -b -k com:pipe,baud=115200,port=\\.\pipe\win7_dbg,resets=0

The guest is a fresh install of Win7 32-bit.

FS base passes all the checks in windbg_on_load() as the guest kernel
loads and it returns true. QEMU then sends some data over the pipe.
Windbg doesn't print anything, it's still showing:

  Opened \\.\pipe\win7_dbg
  Waiting to reconnect...

Is this expected? In regular remote kernel debugging, windbg produces
a bunch of output about the target state when it attaches.

The only thing I can reasonably do at this point is Ctrl+Break. This
results in some data exchange between QEMU and windbg but nothing
really changes -- windbg still says "Waiting to reconnect...". Hitting
Ctrl+Break for the second time kills windbg. I tried running windbg
under windbg and was able to capture this output:

  Debug target initialization failed, 0x8000FFFF

Once I managed to make windbg actually attach (i.e. it generated the
target state output) but the QEMU process died shortly after that. I
don't know why because I haven't been able to reproduce it.

So, what am I doing wrong? Can you post your detailed steps please?

I'm pasting a dump of the pipe traffic as captured with IO Ninja. "<"
is windbg to QEMU, ">" is QEMU to windbg. QEMU initialized the stub at
14:57:48, the first Ctrl+Break was issued at 15:00:32 and the second
one at 15:01:10.

This is very strange.
After reading the desired addresses (windbg_on_load()), the interaction
between the stub and windbg begins. A lot of packets are being sent.
This happens about 10 seconds. All this time "Waiting to reconnect ..."
Then the windbg connects.
In your case windbg does not send packets, more specifically, does not
continue to do it. What is your version of windbg. Also, windbg stub has
been supported only for windbg x64, yet.

Ah, so that's a pretty important piece of information and not very
intuitive given the "Only i386 is supported now." sentence in the
cover email.

Microsoft (R) Windows Debugger Version 10.0.15063.468 X86
Microsoft (R) Windows Debugger Version 10.0.15063.468 AMD64
Microsoft (R) Windows Debugger Version 10.0.16299.15 X86
Microsoft (R) Windows Debugger Version 10.0.16299.15 AMD64

are the versions I have tried. I don't see any difference between x86
and amd64, all versions never connect and crash after the second

What guest OS are you running? Can you maybe zip up your QEMU binaries
and share them with me?


Oh, it looks like a problem in the versions. I use the Windbg from Windows 7. Windbg version: 6.12.0002.633 AMD64. I will try to test with your version.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]