On Mon, Nov 6, 2017 at 7:41 PM, Andrew Baumann <andrew.baum...@microsoft.com> wrote: > Hi, > > I just noticed this thread, and the problem sounded very familiar... > >> From: Ladi Prosek >> Sent: Monday, 6 November 2017 07:16 > [...] >> 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. > > Just a guess, but I suspect the problem you're seeing may be due to the > combination of windbg's tight timing requirements for the serial debug > protocol and qemu's polling-based implementation of named pipe IO. I ran into > this a year or two ago when bringing up raspberry pi... I could never > reliably connect windbg to the emulated serial port using a named pipe. I > believe the problem is that the named pipe driver relies on receiving input > through win_chr_pipe_poll(), which is called too infrequently to satisfy > windbg's needs (it has a rather short timeout before it gives up and > retransmits). The correct fix is to use blocking IO for the named pipes > inside qemu, but I know from experience that win32 is awful in this respect > -- qemu wants a single unified blocking call to wait for IO on any > combination of named pipes, sockets, events, etc. and Windows appears to lack > this, at least at the level of poll/select.
Thanks, I don't usually set up windbg remote debugging over named pipes so this indeed sounded plausible. My Windows runs in a QEMU/KVM VM so to eliminate the pipe I have set up a virtual COM port like so: -serial tcp:127.0.0.1:8889,server,nowait and the nested QEMU ran with: -windbg tcp:10.0.2.2:8889 where 10.0.2.2 is the address assigned to the host with user networking. Windbg then used the default COM1 to connect to the target. I routinely use COMx for remote debugging between VMs with a TCP connection on the host side acting as a null-modem cable and never had any timing related issues. However, the symptoms were exactly the same with this set up. I've also run the original command lines using a pipe on a physical Windows machine, just in case being in a VM somehow screws it up. Again, same issue. At this point I think it would make sense for Mihai to take a look at the trace in my previous email and maybe compare it with what works for him. For completeness, in the unlikely case that it makes a difference, I'm on Win10 (tried 1511 and 1703) and use windbg that comes with one of the latest WDK. Thanks! Ladi > My workaround at the time was to kludge up a proxy between sockets and named > pipes, so the connection was: > qemu <-socket-> proxy <-named pipe-> windbg > > (The proxy was a fairly flaky python script, but it was good enough to tide > me over until I could get kdnet working. I can probably dig it out if you're > interested.) > > Cheers, > Andrew