Troubleshooting 0x109 CRITICAL_STRUCTURE_CORRUPTION

The Debugging Tools for Windows are required to analyze crash dump files. If you do not have the Debugging Tools for Windows installed or dump files are not being generated on system crash, see this post for installation/configuration instructions:

http://www.fergo.co/2011/11/windows-crash-dump-analysis.html

0x00000109 CRITICAL_STRUCTURE_CORRUPTION is a relatively uncommon blue screen error on the Windows Platform (Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, and Windows 8). This error typically indicates that a driver corrupted or attempted to patch the kernel or that there was a RAM issue in the particular DIMM(s) holding the kernel mode code. This is typically not the only blue screen for a system if this is a hardware issue, but may also be accompanied by other blue screens indicating memory issues or driver-related memory corruption (often with a specific exception code of 0xc0000005 STATUS_ACCESS_VIOLATION). If it is solely due to the driver (and not a hardware issue), parameter 4 will be between 0 and 7 indicating what the driver was doing that is not allowed by Microsoft (viruses that attempt to patch the kernel may also cause this error).

Here is an example of a CRITICAL_STRUCTURE_CORRUPTION that is probably due to a memory problem,

2: 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: a3a039d89d42e4f1, Reserved
Arg2: b3b7465eefc0b40f, Reserved
Arg3: fffff80002dcb510, Failure type dependent information
Arg4: 0000000000000000, 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

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from 0000000000000000 to fffff80002c89c40

STACK_TEXT:  
... : nt!KeBugCheckEx


STACK_COMMAND:  kb

SYMBOL_NAME:  ANALYSIS_INCONCLUSIVE

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME:  Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP:  0

FAILURE_BUCKET_ID:  X64_0x109_ANALYSIS_INCONCLUSIVE

BUCKET_ID:  X64_0x109_ANALYSIS_INCONCLUSIVE

Followup: MachineOwner
---------
 

Further troubleshooting/fixes involve determining the nature of the problem (hardware v. software). If it is a hardware issue, troubleshooting falls along the lines of troubleshooting memory problems. If it is specifically due to a driver engaging in an unsupported practice, this driver should be updated to a current version or disabled.

See Also,
Windows Crash Dump Analysis
Troubleshooting Memory Errors
How To Disable and Enable Windows Device Drivers

Any source