none
Windows 8 - CRITICAL_STRUCTURE_CORRUPTION

    Question

  • I am having a kernel-mode driver working perfectly fine with Windows 7 and Windows 8 Dev. Preview. However, same driver leads to BSOD with CRITICAL_STRUCTURE_CORRUPTION error code in Windows 8 Consumer Preview. I have analyzed the crash dump with WinDbg. But, it is pointing to ntoskernel. 

    What can be the issue? 

    Thursday, April 19, 2012 8:37 PM

All replies

  • Here is the output of !analyze -v.

    =====================================================

    MODULE_NAME: nt

    FAULTING_MODULE: fffff8037280e000 nt

    DEBUG_FLR_IMAGE_TIMESTAMP:  4f3f2adb

    CUSTOMER_CRASH_COUNT:  1

    DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

    BUGCHECK_STR:  0x109

    CURRENT_IRQL:  0

    LAST_CONTROL_TRANSFER:  from 0000000000000000 to fffff803729ac140

    STACK_TEXT: 
    fffff880`0231d448 00000000`00000000 : 00000000`00000109 a3a039d8`97cc683f b3b7465e`ea4be13f 00000000`00000004 : nt+0x19e140


    STACK_COMMAND:  kb

    FOLLOWUP_IP:
    nt+19e140
    fffff803`729ac140 48894c2408      mov     qword ptr [rsp+8],rcx

    SYMBOL_STACK_INDEX:  0

    SYMBOL_NAME:  nt+19e140

    FOLLOWUP_NAME:  MachineOwner

    IMAGE_NAME:  ntoskrnl.exe

    BUCKET_ID:  WRONG_SYMBOLS

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

     

    Thursday, April 19, 2012 8:43 PM
  • you need to fix your symbols first before you can get any kind of meaningful analysis. are you are trying to use undocumented fields or APIs or offsets?

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, April 19, 2012 8:45 PM
    Owner
  • Do you have a Kernel Memory Dump enabled?  Also it looks like your symbols are probably wrong, are you using the Microsoft symbol server?  Right now you haven't given enough data for any reasonable deductions.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Thursday, April 19, 2012 8:52 PM
  • Also, if your driver is a KMDF driver you might enable the log so you have a clue what it did before the failure.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Thursday, April 19, 2012 8:53 PM
  • Sorry for not loading the symbols. I have set the Microsoft symbol server path and reanalyzed the dump. Please find below the output.

    *******************************************************************************
    *                                                                             *
    *                        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: a3a039d897cc683f, Reserved
    Arg2: b3b7465eea4be13f, 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

    Debugging Details:
    ------------------

    TRIAGER: Could not open triage file : C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\triage\modclass.ini, error 2

    CUSTOMER_CRASH_COUNT:  1

    DEFAULT_BUCKET_ID:  VERIFIER_ENABLED_VISTA_MINIDUMP

    BUGCHECK_STR:  0x109

    PROCESS_NAME:  System

    CURRENT_IRQL:  2

    LAST_CONTROL_TRANSFER:  from 0000000000000000 to fffff803729ac140

    STACK_TEXT: 
    fffff880`0231d448 00000000`00000000 : 00000000`00000109 a3a039d8`97cc683f b3b7465e`ea4be13f 00000000`00000004 : nt!KeBugCheckEx


    STACK_COMMAND:  kb

    FOLLOWUP_IP:
    nt+19e140
    fffff803`729ac140 48894c2408      mov     qword ptr [rsp+8],rcx

    SYMBOL_STACK_INDEX:  0

    SYMBOL_NAME:  nt+19e140

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: nt

    IMAGE_NAME:  ntkrnlmp.exe

    DEBUG_FLR_IMAGE_TIMESTAMP:  4f3f2adb

    FAILURE_BUCKET_ID:  X64_0x109_VRF_nt+19e140

    BUCKET_ID:  X64_0x109_VRF_nt+19e140

    Followup: MachineOwner

    Thursday, April 19, 2012 8:58 PM
  • Also, if your driver is a KMDF driver you might enable the log so you have a clue what it did before the failure.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr


    I have enabled the WPP tracing in my KMDF. But, the given BSOD occurs at a random duration. My driver has just added the device and performed the prepare hardware. It is not performing any operations when BSOD occurs.
    Thursday, April 19, 2012 9:02 PM
  • Just because it isn't performing operations doesn't mean that it is not the culprit.  Have you run the driver under driver verifier?  Also, go from a mini-dump to a kernel dump without it you only get part of the picture.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Thursday, April 19, 2012 9:04 PM
  • I have enabled the kernel dump (System->Advanced system settings->Advanced->Startup and Recovery->System Failure). However, no kernel dump file is generated.

    As you can see from the MiniDump, fourth argument is 0000000000000015. What can be the corruption type associated with this number?

    Thursday, April 26, 2012 3:34 PM
  • @Doron, @Donald,

    I would really appreciate if you could please provide your guidance on how to debug this issue further.

    Thanks

    Thursday, April 26, 2012 6:59 PM
  • You did not do what Don asked you to: take a kernel dump, NOT a mini-dump. Have you set breakpoints and stepped into your code? A little judicious time spent stepping into code can answer your questions far faster than any forum or postmortem crash dump will.

    Gary G. Little NanoTelesis Systems, LLC

    Thursday, April 26, 2012 7:27 PM
  • Turn on driver verifier, and be sure KMDF logging is on.  If this is reproducable in Windows 7 use a checked kernel and HAL.  Then start debugging. 

    Doron or one of the MVP's who has access to the kernel sources may be able to give you what the fourth parameter being 15 means.  Unfortunately since they eliminated the WDK MVP's there are fewer folks who can do that.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Thursday, April 26, 2012 7:33 PM
  • You did not do what Don asked you to: take a kernel dump, NOT a mini-dump. Have you set breakpoints and stepped into your code? A little judicious time spent stepping into code can answer your questions far faster than any forum or postmortem crash dump will.

    Gary G. Little NanoTelesis Systems, LLC

    Thank you for you post. As you can seem from my post, I have enabled the kernel dump by going into
    (System->Advanced system settings->Advanced->Startup and Recovery->System Failure). However, somehow no dump file is generated.

    Stepping through the code may not be useful as the crash is occuring at random amount of time. When the BSOD is occurs, none of my driver code is executing. It seems to me that my driver is updating something (or corrupting something) which Windows integrity checker checks later on and gives BSOD.

    Thursday, April 26, 2012 7:44 PM
  • Turn on driver verifier, and be sure KMDF logging is on.  If this is reproducable in Windows 7 use a checked kernel and HAL.  Then start debugging. 

    Doron or one of the MVP's who has access to the kernel sources may be able to give you what the fourth parameter being 15 means.  Unfortunately since they eliminated the WDK MVP's there are fewer folks who can do that.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Thanks for the post. I have turned on the drive verifier and it was running when the system blue screen. I am not sure how to extract any useful information by using driver verifier. I am new to Windows driver development.

    The issue is not reproducible in Windows 7 and Windows 8 Developer Preview. It occurs only in Windows 8 Consumer Preview.

    Thursday, April 26, 2012 7:47 PM
  • Then Doron or another Microsoft employee are the only ones who can help with the 4th parameter being 15. 

    Do you compile your driver with /W4 and use PreFast (code analsis in the Win8 WDK) to look for bugs?  This is most likely your driver using an incorrect pointer, so using the above and if needed using static driver verifier may help find you error.

    Other than the above, you are going to have to step through the code and check every pointer usage for invalid pointers.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Thursday, April 26, 2012 7:54 PM
  • The operative phrase there is "may not be useful", which tells me you haven't stepped into your code, and therefore have no idea whether actively running the debugger and setting some breakpoints will or will not be useful. Setting one in DriverEntry would probably be very informative.


    Gary G. Little NanoTelesis Systems, LLC

    Thursday, April 26, 2012 7:54 PM
  • HI U_K,

    Being new to kernel-mode driver development can be ... frustrating.  Using the driver verifier (and KMDF verifier if a KMDF driver) is an important step to keeping all your hair and fingernails.

    If you're not already using driver verifier during your development process, you're doing too much work.  :)  Here's a shortcut to get you started (based on Win7's verifier.exe):

    1. Run verifier.exe from an elevated cmd prompt
    2. First, choose "Create custom settings (for code developers)"
    3. Next, choose "Select individual settings from a full list"
    4. Now, to detect the above issues, enable at least the following settings:  Special Pool, Pool Tracking, I/O Verification  ((Optionally, also enable DMA checking))
    5. Next, choose "Select driver names from a list"
    6. Select your own driver, as well as the other drivers that load above and below you in the stack
    7. Also, select any drivers for audio devices where the "provider" column doesn't indicate Microsoft wrote it ((call me jaded, it's saved me time in the past))
    8. Finish (exit verifier), reboot the system, and repro the problem

    You may also need to enable KMDF's verifiers.  A good article I referred to wasTen Things You Need To Know About KMDF, which lists a way to make this painless via a modified INF (use only during debugging, obviously).

    Anyways, when it next bugchecks, you should have a different error code, and it should be quite close to the cause of the error.  Next steps include:

    1. Run the standard ".symfix;.srcfix;.reload;!analyze -v" to get a good starting point
    2. "k" gives you stack traces, "kp" adds parameters (when available)
    3. KMDF includes logging functionality, which helps you figure out what you did recently if you add it to your souce code....

    Best of luck!


    Registered Patent Agent | LCA - Patents | Microsoft

    Saturday, April 28, 2012 4:44 AM