none
CRITICAL_STRUCTURE_CORRUPTION BSOD RRS feed

  • Question

  • Hi,

    I need a help with finding the root cause to a BSOD I have with my KMDF driver.

    I have a KMDT driver, which is a SW only driver (doesn’t read from/write to HW), and a C++ application that reads from it  and writes to it.

    Once in a few runs a BSOD occurs from type:

    BugCheck 109, {a3a01f591128b8ef, b3b72bdf63a8bc7e, 34000000000, 17}

    (4<sup>th</sup> parameter is always 17).

    Whenever it occurs, the stacks in the machine don’t include any flow of my driver, and I don’t see it in the processes list too. I can just see one stack (every time a different one) with some system calls.

    After typing “analyze –v” I get the next details:

    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: a3a01f591128b8ef, Reserved

    Arg2: b3b72bdf63a8bc7e, 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

    Debugging Details:

    ------------------

    DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

    BUGCHECK_STR:  0x109

    PROCESS_NAME:  System

    CURRENT_IRQL:  2

    STACK_TEXT: 

    ffffd001`40ed18d8 fffff802`4786af1e : 00000000`00000000 00000000`00000000 ffffd001`40ed1a40 fffff802`4775cde8 : nt!DbgBreakPointWithStatus

    ffffd001`40ed18e0 fffff802`4786a82f : 00000000`00000003 a3a01f59`1128b8ef fffff802`477e6180 00000000`00000109 : nt!KiBugCheckDebugBreak+0x12

    ffffd001`40ed1940 fffff802`477d82a4 : 00000000`00000000 00000000`00000001 00000000`00000000 00000000`00000000 : nt!KeBugCheck2+0x8ab

    ffffd001`40ed2050 00000000`00000000 : 00000000`00000109 a3a01f59`1128b8ef b3b72bdf`63a8bc7e 00000340`00000000 : nt!KeBugCheckEx+0x104

    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:  0x109_17_ANALYSIS_INCONCLUSIVE

    BUCKET_ID:  0x109_17_ANALYSIS_INCONCLUSIVE

    Followup: MachineOwner

    I tried a lot to get more information from the dump file, but nothing. And when I add my driver WPP trace it seems that everything is ok.

    Anyone has an idea what can I do? What should I check?

    Thanks,

    C.S

    Tuesday, November 18, 2014 7:41 PM