Bugcheck 0x109 CRITICAL_STRUCTURE_CORRUPTION

NTDEV
1

I have seen this posted before, with little information forth coming from the MSFT guys, but trying this and crossing my fingers.

I am getting the following bugcheck on a box with a haswell processor (not sure it matters, but don’t see it on other targets) running Windows 8 RTM.

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: a3a039d898a91642, Reserved
    Arg2: b3b7465eeb28c0df, Reserved
    Arg3: 0000000000000004, Failure type dependent information
    Arg4: 0000000000000015, 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

I cannot find anyone who has figured out what 15 means for arg4. Arg3 is obviously not a pointer to anything useful, so the stock response for this bugcheck does not suffice.

This box bugchecks with this output about once a month. It always happens when my driver is running on the box, but my driver is running on the box most of the time. I don’t really have a month to not use the box and see if it happens.

I have run driver verifier against everything on this box (including my driver) with no help.

I don’t believe my driver is touching anything it shouldn’t be, so I am clueless as to what is causing this issue.

Btw, it can’t seem to determine what driver that is causing the issue:

SYMBOL_NAME: ANALYSIS_INCONCLUSIVE

I just really really really, that is really really really, want to know what arg4 with a value of 15 means. Is this some kind of state secret?

Thanks!!

Fred

2

Do you have a debugger attached at the time of bugcheck?

3

Yes, that is where that output came from.

4

Check if you have stray breakpoints in the debugger:

bl

Clear them if there are any.

5

Ah, I see what you are getting at. Yeah, that isn’t the problem. This machine runs with a debugger attached so we can catch crashes like these, but in general it is not actively debugged. The box runs builds of our software every night. And once a month or so the bugcheck occurs. Even if it were a debug breakpoint, I would really like to know what patchguard doesn’t like, so I can rule out my driver as the cause of the issue.

I have seen reports of memory errors and all kinds of nonsense causing PG errors. But, not having these details leaves me in the blind. I can see that MSFT wants to limit people’s understanding of their security tool, but without knowing the rules, how do we know how we are violating them?

Also, if this is some kind of malware that got on our system, we really need to know that as well.

6

Btw, this brings up another interesting point. It used to be that if you booted a target with a kernel debugger attached, then patch guard was turned off. I am guessing this is no longer true? When did that change?

7

Something on your machine has altered a bit in CR0 that the OS considers owned by itself (e.g. CR0.WP).

  • S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, March 06, 2014 4:13 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Bugcheck 0x109 CRITICAL_STRUCTURE_CORRUPTION

I have seen this posted before, with little information forth coming from the MSFT guys, but trying this and crossing my fingers.

I am getting the following bugcheck on a box with a haswell processor (not sure it matters, but don’t see it on other targets) running Windows 8 RTM.

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: a3a039d898a91642, Reserved
    Arg2: b3b7465eeb28c0df, Reserved
    Arg3: 0000000000000004, Failure type dependent information
    Arg4: 0000000000000015, 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

I cannot find anyone who has figured out what 15 means for arg4. Arg3 is obviously not a pointer to anything useful, so the stock response for this bugcheck does not suffice.

This box bugchecks with this output about once a month. It always happens when my driver is running on the box, but my driver is running on the box most of the time. I don’t really have a month to not use the box and see if it happens.

I have run driver verifier against everything on this box (including my driver) with no help.

I don’t believe my driver is touching anything it shouldn’t be, so I am clueless as to what is causing this issue.

Btw, it can’t seem to determine what driver that is causing the issue:

SYMBOL_NAME: ANALYSIS_INCONCLUSIVE

I just really really really, that is really really really, want to know what arg4 with a value of 15 means. Is this some kind of state secret?

Thanks!!

Fred

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

8

Skywing er uh, Mr. Johnson,

MUCH thanks for the information!! Big fan of your past articles too (Uninformed, etc.)!

This helps a bunch, I have an idea of what on my system might be causing this. Can’t thank you enough actually.

Fred

9

So, just got the bugcheck again and, if WinDbg’s register window is to be believed, CR0 contains exactly what it did on fresh install of the OS on all 8 processors: 0x80050033.

Any hint as to what the other arguments to this bugcheck mean, or something else I can look at? I am at a loss.

Thx!

Fred

10

My apologies, apparently I misread the initial !analyze report in haste. You’ll want to look at CR4 and not CR0.

Subtype 0x15 indicates that the bit pattern in a processor control register attained an unexpected value. Bug parameter 3 indicates the control register ordinal (i.e. 0 - CR0, 4 - CR4, etc.).

  • S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Monday, March 10, 2014 5:27 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Bugcheck 0x109 CRITICAL_STRUCTURE_CORRUPTION

So, just got the bugcheck again and, if WinDbg’s register window is to be believed, CR0 contains exactly what it did on fresh install of the OS on all 8 processors: 0x80050033.

Any hint as to what the other arguments to this bugcheck mean, or something else I can look at? I am at a loss.

Thx!

Fred

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

11

I figured that 3rd arg out after I posted the question! Thanks for the response though, and for your help in general!

Fred