x64 kernel patch guard and GDT corruption

I run a test on a 4 logical CPU Windows 2003 x64 system.
Windows crashes with a BSOD and a kernel dump after few hours
of running the test. Here is the WinDbg output:

0: kd> !analyze -v
*****************************************************************************
**
*
*
* Bugcheck Analysis
*
*
*
*****************************************************************************
**

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code
or
data have been corrupted. There are generally three causes for a corruption:

  1. A driver has inadvertently or deliberately modified critical kernel code
    or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
  2. A developer attempted to set a normal kernel breakpoint using a kernel
    debugger that was not attached when the system was booted. Normal
    breakpoints,
    “bp”, can only be set if the debugger is attached at boot time. Hardware
    breakpoints, “ba”, can be set at any time.
  3. A hardware corruption occurred, e.g. failing RAM holding kernel code or
    data.
    Arguments:
    Arg1: a3a03a382c85662e, Reserved
    Arg2: b3b746be7f020f8b, Reserved
    Arg3: fffffadf90a73b00, Failure type dependent information
    Arg4: 0000000000000003, Type of corrupted region, can be
    0 : A generic data region
    1 : Modification of a function or .pdata
    2 : A processor IDT
    3 : A processor GDT
    4 : Type 1 process list corruption
    5 : Type 2 process list corruption
    6 : Debug routine modification
    7 : Critical MSR modification

Debugging Details:

BUGCHECK_STR: 0x109_LDR

DEFAULT_BUCKET_ID: DRIVER_FAULT

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 0000000000000000 to 0000000000000000

STACK_TEXT:
0000000000000000 0000000000000000 : 0000000000000000 0000000000000000
0000000000000000 0000000000000000 : 0x0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

STACK_COMMAND: kb

BUCKET_ID: INVALID_KERNEL_CONTEXT

Followup: MachineOwner

I’ve dump GDTs of all 4 CPUs and they look intact.
How do I know that the kernel has a corrupted GDT and not a corrupted
CRC for the GDT? Does the kernel patch guard code keep redundant CRCs
for the protected code and data?

Microsoft doesn’t provide any public documentation about
the kernel patch guard and doesn’t provide symbols for the relevant
functions.

Dmitriy Budko, VMware