When the debugger drops the serial link uncleanly mid-frame (no CLOSE_AND_UNLOAD packet), SerialConnectionRecvBuffer overflowed without an end-of-buffer marker and returned FALSE into the KD dispatch loop retry. The loop re-entered the same desynced stream, so it overflowed again at once and flooded 'buffer exceeds the buffer limitation' (and could wedge the KD driver on the next reconnect). Discard bytes to the next end-of-buffer marker to re-align, start a fresh frame, and log once per desync episode with LogWarning. Framing and protocol are unchanged.
Refs #661
- Implement IOCTL_DEBUGGER_CPUID handler
- Fill CPUID response with register values and leaf data
- Add max sub-leaf detection for some special leaves like 0x4, 0xB and...
- Add SGX support detection via leaf 7
- Add ucpuid command to commands.h and help.h
- Add IOCTL definitions for CPUID
- Use macros for CPUID leaf decoding
- Update Connection.h with new packet types
In Debugger Mode, breaking the debuggee and then reading registers (e.g. the
'r' command) could bugcheck the debuggee with DRIVER_IRQL_NOT_LESS_OR_EQUAL
(0xD1) at IRQL 0xff.
Root cause: DebuggerCommandReadRegisters() copies GUEST_REGS from
DbgState->Regs, but the per-core DbgState->Regs is only populated on the
event-triggered halt paths. A core halted via a manual break
(DEBUGGER_VMCALL_VM_EXIT_HALT_SYSTEM) or via the NMI broadcast (KdHandleNmi)
never had DbgState->Regs set, so it was NULL and the GUEST_REGS memcpy
dereferenced address 0.
Fix:
- Add VmFuncGetGuestRegs(CoreId) returning g_GuestState[CoreId].Regs (the
guest GP registers saved on the last vm-exit).
- Populate DbgState->Regs from it on the two manual-halt entry points
(DEBUGGER_VMCALL_VM_EXIT_HALT_SYSTEM and KdHandleNmi) so register reads on a
manually-halted core return the correct values.
- Add a defensive NULL check in DebuggerCommandReadRegisters().
