CRITICAL_STRUCTURE_CORRUPTION BSOD

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}
(4th 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:
ffffd00140ed18d8 fffff8024786af1e : 0000000000000000 0000000000000000 ffffd00140ed1a40 fffff8024775cde8 : nt!DbgBreakPointWithStatus
ffffd00140ed18e0 fffff8024786a82f : 0000000000000003 a3a01f591128b8ef fffff802477e6180 0000000000000109 : nt!KiBugCheckDebugBreak+0x12
ffffd00140ed1940 fffff802477d82a4 : 0000000000000000 0000000000000001 0000000000000000 0000000000000000 : nt!KeBugCheck2+0x8ab
ffffd00140ed2050 0000000000000000 : 0000000000000109 a3a01f591128b8ef b3b72bdf63a8bc7e 0000034000000000 : 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,

xxxxx@intel.com wrote:

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}
(4th 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.

Have you looked at the other processors? You can say 0kb, 1kb, 2kb, 3kb
etc to see the current stacks for all of your processors. However, a
memory corruption often isn’t detected until a long time after the
original perpetrator is gone.

Does your driver poke around in the kernel data structures? It’s not
impossible that you have a single-bit memory error. You might consider
running a memory test for a while.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

It seems like the key would be knowing what type 0x17 is.

Unfortunately, CRITICAL_STRUCTURE_CORRUPTION is throw by Patch Guard… given that these sources are restricted, there aren’t a lot of people who will be able to decode the bugcheck parameters for you.

Peter
OSR
@OSRDrivers

From a thread earlier this year (http://www.osronline.com/showthread.cfm?link=255384)

"
22 Apr 14 13:44
Ken Johnson
xxxxx@valhallalegends.com
Join Date: 24 Jul 2008
Posts To This List: 1001
Bugcheck 0x109 CRITICAL_STRUCTURE_CORRUPTION (Arg4 = 17)
This indicates that a processor local APIC was unexpectedly reprogrammed. Is
your driver directly reconfiguring the local APIC in any way?

  • S (Msft)
    "

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Tuesday, November 18, 2014 12:16 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] CRITICAL_STRUCTURE_CORRUPTION BSOD

It seems like the key would be knowing what type 0x17 is.

Unfortunately, CRITICAL_STRUCTURE_CORRUPTION is throw by Patch Guard… given that these sources are restricted, there aren’t a lot of people who will be able to decode the bugcheck parameters for you.

Peter
OSR
@OSRDrivers


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

NICE FIND Mr. Edwards. Bravo!

So there you have it…

Peter
OSR
@OSRDrivers