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:
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.
A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a01f5897b106b8, Reserved
Arg2: b3b72bdeea3108b3, Reserved
Arg3: 0000034000000000, Failure type dependent information
Arg4: 0000000000000017, 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
This indicates that a processor local APIC was unexpectedly reprogrammed. Is your driver directly reconfiguring the local APIC in any way?
S (Msft)
From: xxxxx@birulevo.netmailto:xxxxx Sent: ?4/?21/?2014 8:36 To: Windows System Software Devs Interest Listmailto:xxxxx Subject: [ntdev] Bugcheck 0x109 CRITICAL_STRUCTURE_CORRUPTION (Arg4 = 17)
Hi,
I’m trying to debug my driver and looks like I have PatchGuard fun.
Does anyone know which structurer was corrupted and meaning of Arg3 for this case?
Thanks in advance / Roman
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: a3a01f5897b106b8, Reserved Arg2: b3b72bdeea3108b3, Reserved Arg3: 0000034000000000, Failure type dependent information Arg4: 0000000000000017, 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
If this is for non-production use–in other words, you only intend to run this code on a few machines of yours and not distribute it to customers–you can disable PatchGuard.
Try setting the boot configuration to enable kernel debugging as network card mode with 127.0.0.1:50000 as the target IP address. This will fail, but by virtue of initializing the kernel debugger, PatchGuard won’t start.
*Please* don’t use this in anything you give to customers.
(BTW, this even works with Secure Boot enabled if I use my exploit to enable the debugger despite Secure Boot. =) )