Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at:

x64 kernel patch guard and GDT corruption

Dmitriy_BudkoDmitriy_Budko Member Posts: 164
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

This bugcheck is generated when the kernel detects that critical kernel code
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
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal
"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
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:




LAST_CONTROL_TRANSFER: from 0000000000000000 to 0000000000000000

00000000`00000000 00000000`00000000 : 00000000`00000000 00000000`00000000
00000000`00000000 00000000`00000000 : 0x0


MODULE_NAME: Unknown_Module

IMAGE_NAME: Unknown_Image




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

Dmitriy Budko, VMware
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE