while(1); is not really a good solution. It should be something that is
visible in GDB.
But I fear that a KeBugCheck() won't work here, since it will rely on a
working KD connection.
Maybe a KD_ASSERT() macro, that calls KdAssert() on failure or
something, resets the GDB connection somehow, issues a debug print and
then halts.
Am 12.09.2014 22:23, schrieb jgardou(a)svn.reactos.org:
  Author: jgardou
 Date: Fri Sep 12 20:23:08 2014
 New Revision: 64127
 URL: 
http://svn.reactos.org/svn/reactos?rev=64127&view=rev
 Log:
 [KDGDB]
  - Add a callback mechanism permitting to "simulate" KD send <-> receive
loop without having to actually communicate to GDB
  - Use that to update the program counter when cont'ing a breakpoint
 Now cont'ing an assertion failure is possible, since we actually get beyond the int 3
instruction
 Modified:
     trunk/reactos/drivers/base/kdgdb/gdb_input.c
     trunk/reactos/drivers/base/kdgdb/kdgdb.h
     trunk/reactos/drivers/base/kdgdb/kdpacket.c
 +)
 +{
 +    DBGKD_MANIPULATE_STATE64* State =
(DBGKD_MANIPULATE_STATE64*)MessageHeader->Buffer;
 +
 +    /* We just confirm that all went well */
 +    if ((PacketType != PACKET_TYPE_KD_STATE_MANIPULATE)
 +            || (State->ApiNumber != DbgKdSetContextApi)
 +            || (State->ReturnStatus != STATUS_SUCCESS))
 +    {
 +        /* Should we bugcheck ? */
 +        while (1);
 +    }
 +}
 +
 +static
 +KDSTATUS
 +SetContext(
 +    _Out_ DBGKD_MANIPULATE_STATE64* State,
 +    _Out_ PSTRING MessageData,
 +    _Out_ PULONG MessageLength,
 +    _Inout_ PKD_CONTEXT KdContext,
 +    _In_opt_ KDP_MANIPULATESTATE_HANDLER ManipulateStateHandler
 +)
 +{
 +    State->ApiNumber = DbgKdSetContextApi;
 +    State->Processor = CurrentStateChange.Processor;
 +    State->ReturnStatus = STATUS_SUCCESS;
 +    State->ProcessorLevel = CurrentStateChange.ProcessorLevel;
 +    MessageData->Length = sizeof(CurrentContext);
 +
 +    if (MessageData->MaximumLength < sizeof(CurrentContext))
 +    {
 +        while (1);
 +    }
 +