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

[Ladi Prosek]

On Wed, Nov 8, 2017 at 3:28 PM, Mihail Abakumov
<address@hidden> wrote:
> 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:
>>>
>>> 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
>> break.
>>
>> What guest OS are you running? Can you maybe zip up your QEMU binaries
>> and share them with me?
>>
>> Thanks,
>> Ladi
>
>
> 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.

Looks like it's the -b switch making the difference here. It was
removed in later versions of windbg.


Windbg docs (older):

-b
(Kernel mode only) This option has two effects:
1. The debugger will break into the target computer immediately upon connection.

2. After a reboot, the debugger will break into the target computer
once the kernel is initialized. See Crashing and Rebooting the Target
Computer for details and for other methods of changing this status.


Windbg docs (newer):

-b
This option is no longer supported.


-b makes windbg send a break-in right after connecting. Apparently
there is a short time window when the break-in will work. I can
actually successfully connect with a Win10 windbg (so without -b) if I
hit Ctrl+Break shortly after the initial handshake. This also explains
why I was able to connect once during my initial testing. I was just
lucky and hit Ctrl+Break soon enough after connecting.

By initial handshake I mean this sequence (I have added a simple
logging, should be clear what it means):

Received control PACKET_TYPE_KD_RESET
Sending data 7
Sending control 6

Newer debuggers without -b will stop here. Older debuggers with -b
will continue with:

Received RESULT_BREAKIN_BYTE
Sending data 7
Received RESULT_BREAKIN_BYTE
Sending data 7
Received data PACKET_TYPE_KD_STATE_MANIPULATE (12614)
Sending control 4
Sending data 2
Received data PACKET_TYPE_KD_STATE_MANIPULATE (12592)
Sending control 4
Sending data 2
Received data PACKET_TYPE_KD_STATE_MANIPULATE (12592)
Sending control 4
Sending data 2
...


Next step, when I have time, is to find the differences between
sending the break-in early and sending it later. Also interesting
would be recording the exchange between windbg and the target when
doing regular remote kernel debugging. I would still expect to see the
"Connected to Windows 7 7601 x86 compatible target ..." output always,
even when not breaking in immediately. The handshake is likely still
missing something.

Thanks,
Ladi