none
BSOD in FxDriverEntry with __security_init_cookie on Windows 7 RRS feed

  • Question

  • Hi,

    We are developing a KMDF driver.

    We compiled this driver using VS2012 + WDK 8.0

    But we had to recompile this driver using VS2013 + WDK 8.1

    This recompiled driver on Windows 8.1 & 8 is working fine, but on Windows 7 we got a BSOD, here the callstack :

    STACK_TEXT:  

    nt!RtlpBreakWithStatusInstruction
    nt!KiBugCheckDebugBreak+0x1c
    nt!KeBugCheck2+0x68b
    nt!KiSystemFatalException+0xf
    OurDriver!__security_init_cookie+0x1b [d:\wbrtm\minkernel\tools\gs_support\kmodefastfail\gs_support.c @ 45]
    OurDriver!FxDriverEntry+0xa [d:\w8rtm\minkernel\wdf\framework\kmdf\src\dynamic\stub\stub.cpp @ 205]
    nt!IopLoadDriver+0x7ed
    nt!PipCallDriverAddDeviceQueryRoutine+0x34b
    nt!RtlpCallQueryRegistryRoutine+0x292
    nt!RtlQueryRegistryValues+0x414
    nt!PipCallDriverAddDevice+0x383
    nt!PipProcessDevNodeTree+0x15d
    nt!PiRestartDevice+0x8a
    nt!PnpDeviceActionWorker+0x1fb
    nt!ExpWorkerThread+0x10d
    nt!PspSystemThreadStartup+0x9e
    nt!KiThreadStartup+0x19

    I'll try to remove usage of /GS in VS2013 but it won't workaround the issue.

    Any hint on this issue ?

    Thank you.
    Tuesday, June 10, 2014 8:25 AM

Answers

  • what is the output of !analyze -v? if you are targeting windows 8 or 8.1 as the OS target in the build you get a different BufferOverflowK.lib version (which is what adds support for /GS) which requires 8 or 8.1 to initialize properly.  if you want to run on win7, you need to set winy as an os build target.

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

    Tuesday, June 10, 2014 6:30 PM

All replies

  • This is typically because of a stack based buffer overflow.  If you have a large structure or array as a local variable, allocate the memory and keep the pointer on the stack.  The other problem is that your go beyond the length of the structure or the array.  Run Code Analysis (PreFast) on the driver this will help find these.


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

    Tuesday, June 10, 2014 10:44 AM
  • Thank you for your answer, but If I'm not wrong, FxDriverEntry is called by the framework before DriverEntry which is the first driver function to get called.

    If it crash in FxDriverEntry, that's mean DriverEntry is not yet called and my driver code is not executed. That's why I'm asking.

    Building the driver with an older WDK/VS hide the issue, but that's not a solution as we have other issues with older WDK/VS.


    • Edited by cgeff Tuesday, June 10, 2014 11:57 AM
    Tuesday, June 10, 2014 11:54 AM
  • what is the output of !analyze -v? if you are targeting windows 8 or 8.1 as the OS target in the build you get a different BufferOverflowK.lib version (which is what adds support for /GS) which requires 8 or 8.1 to initialize properly.  if you want to run on win7, you need to set winy as an os build target.

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

    Tuesday, June 10, 2014 6:30 PM
  • Thank you for your answer.

    We are targeting Windows 7, 8 and 8.1. But from your comment, we should build a driver for Windows 7 and then build another driver for 8 & 8.1
    I though that KMDF driver can supports all windows (> Vista) ?

    Do you think it's possible to build a driver compatible for these 3 Windows ? With previous WDK we were able to do so.


    Here the "!analyze -v" output :

    1: kd> !analyze -v
    Connected to Windows 7 7601 x86 compatible target at (Wed Jun 11 14:08:45.595 2014 (UTC + 2:00)), ptr64 FALSE
    Loading Kernel Symbols
    .....................

    Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
    Run !sym noisy before .reload to track down problems loading symbols.

    ..........................................
    ................................................................
    ............
    Loading User Symbols

    Loading unloaded module list
    ............Unable to enumerate user-mode unloaded modules, Win32 error 0n30
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    UNEXPECTED_KERNEL_MODE_TRAP (7f)
    This means a trap occurred in kernel mode, and it's a trap of a kind
    that the kernel isn't allowed to have/catch (bound trap) or that
    is always instant death (double fault).  The first number in the
    bugcheck params is the number of the trap (8 = double fault, etc)
    Consult an Intel x86 family manual to learn more about what these
    traps are. Here is a *portion* of those codes:
    If kv shows a taskGate
            use .tss on the part before the colon, then kv.
    Else if kv shows a trapframe
            use .trap on that value
    Else
            .trap on the appropriate frame will show where the trap was taken
            (on x86, this will be the ebp that goes with the procedure KiTrap)
    Endif
    kb will then show the corrected stack.
    Arguments:
    Arg1: 0000000d, EXCEPTION_GP_FAULT
    Arg2: 00000000
    Arg3: 00000000
    Arg4: 00000000

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


    BUGCHECK_STR:  0x7f_d

    DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

    PROCESS_NAME:  System

    CURRENT_IRQL:  2

    ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) amd64fre

    LOCK_ADDRESS:  83368cc0 -- (!locks 83368cc0)

    Resource @ nt!PiEngineLock (0x83368cc0)    Exclusively owned
        Contention Count = 12
         Threads: 855e7920-01<*> 
    1 total locks, 1 locks currently held

    PNP_TRIAGE: 
    Lock address  : 0x83368cc0
    Thread Count  : 1
    Thread address: 0x855e7920
    Thread wait   : 0x16c5

    LAST_CONTROL_TRANSFER:  from 832e0d5f to 8327c7b8

    STACK_TEXT:  
    8cbac0ec 832e0d5f 00000003 87d4f9b6 00000065 nt!RtlpBreakWithStatusInstruction
    8cbac13c 832e185d 00000003 ad0361bf 86bd5ac8 nt!KiBugCheckDebugBreak+0x1c
    8cbac500 832432bf 0000007f 0000000d 00000000 nt!KeBugCheck2+0x68b
    8cbac500 ad0361bf 0000007f 0000000d 00000000 nt!KiSystemFatalException+0xf
    8cbac590 ad0322f8 8cbac77c 833c53b2 86bd5ac8 ourdriver!__security_init_cookie+0x1b [d:\wbrtm\minkernel\tools\gs_support\kmodefastfail\gs_support.c @ 45]
    8cbac598 833c53b2 86bd5ac8 85fa0000 c000035f ourdriver!FxDriverEntry+0xa [d:\w8rtm\minkernel\wdf\framework\kmdf\src\dynamic\stub\stub.cpp @ 205]
    8cbac77c 833b18b8 00000000 00000000 8cbac7a4 nt!IopLoadDriver+0x7ed
    8cbac828 833f595d abd5d9b0 00000001 abd5d98c nt!PipCallDriverAddDeviceQueryRoutine+0x34b
    8cbac860 833f66ca 00000001 8cbac92c c0000034 nt!RtlpCallQueryRegistryRoutine+0x2ea
    8cbac8cc 833bf76e 40000000 800009b4 8cbac948 nt!RtlQueryRegistryValues+0x31d
    8cbac9a8 833beedc 855681d8 8cbacbd0 85f03f08 nt!PipCallDriverAddDevice+0x383
    8cbacba4 8348edfc 855681d8 85f03f08 8cbacbd0 nt!PipProcessDevNodeTree+0x15d
    8cbacbd8 83216cc3 83366be0 855e7920 8333d3bc nt!PiRestartDevice+0x8a
    8cbacc00 8327f14b 00000000 00000000 855e7920 nt!PnpDeviceActionWorker+0x1fb
    8cbacc50 8340b141 00000001 87d4f41a 00000000 nt!ExpWorkerThread+0x10d
    8cbacc90 832b2559 8327f03e 00000001 00000000 nt!PspSystemThreadStartup+0x9e
    00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19


    STACK_COMMAND:  kb

    FOLLOWUP_IP: 
    ourdriver!__security_init_cookie+1b [d:\wbrtm\minkernel\tools\gs_support\kmodefastfail\gs_support.c @ 45]
    ad0361bf cd29            int     29h

    FAULTING_SOURCE_LINE:  d:\wbrtm\minkernel\tools\gs_support\kmodefastfail\gs_support.c

    FAULTING_SOURCE_FILE:  d:\wbrtm\minkernel\tools\gs_support\kmodefastfail\gs_support.c

    FAULTING_SOURCE_LINE_NUMBER:  45

    FAULTING_SOURCE_CODE:  
    No source found for 'd:\wbrtm\minkernel\tools\gs_support\kmodefastfail\gs_support.c'


    SYMBOL_STACK_INDEX:  4

    SYMBOL_NAME:  ourdriver!__security_init_cookie+1b

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: ourdriver

    IMAGE_NAME:  ourdriver.sys

    DEBUG_FLR_IMAGE_TIMESTAMP:  5395ce83

    IMAGE_VERSION:  1.0.1.11111

    FAILURE_BUCKET_ID:  0x7f_d_ourdriver!__security_init_cookie+1b

    BUCKET_ID:  0x7f_d_ourdriver!__security_init_cookie+1b

    ANALYSIS_SOURCE:  KM

    FAILURE_ID_HASH_STRING:  km:0x7f_d_ourdriver!__security_init_cookie+1b

    FAILURE_ID_HASH:  {13526058-0c4b-edf2-a6e6-657cf8f8ed06}

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

    Thank you.
    Wednesday, June 11, 2014 12:17 PM
  • If you build for Win7 it should run fine on all three platforms.  What is not supported is building for a later platform and then running it on an earlier platform.


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

    Wednesday, June 11, 2014 12:26 PM
  • If you build for Win7 it should run fine on all three platforms.  What is not supported is building for a later platform and then running it on an earlier platform.


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

    The driver is built from Visual Studio 2013. The project is built using the Platform toolset "WindowsKernelModeDriver8.1". There is no option for Windows 7 driver. You mean I should install old Windows 7 Driver Kit to build the driver ? That's strange, WDK should be all inclusive :

    http://msdn.microsoft.com/en-us/windows/hardware/gg454513.aspx

    Start by downloading Visual Studio 2013. Used together, Visual Studio 2013 and the Windows Driver Kit 8.1 Update provide an integrated development environment for creating efficient, high-quality drivers for Windows 8.1 Update, 8.1, 8, and 7.

    Thank you.


    Wednesday, June 11, 2014 1:08 PM
  • Under the configuration manager in the build menu you should be able to chose Win7 as the target.


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

    Wednesday, June 11, 2014 1:15 PM
  • Ok, I got the point, you mean the project should use <TargetVersion>Windows7</TargetVersion> instead of <TargetVersion>WindowsV6.3</TargetVersion> (in vcxproj)

    Thank you.
    Wednesday, June 11, 2014 2:04 PM
  • Hi, 

    After some testing :

    using in vcxproj :

    <PropertyGroup ....>
        <TargetVersion>WindowsV6.3</TargetVersion>
        <KernelBufferOverflowLib>$(DDK_LIB_PATH)\BufferOverflowK.lib</KernelBufferOverflowLib>

    or simply :

    <PropertyGroup ....>
        <TargetVersion>Windows7</TargetVersion>

    solve the issue. The driver install without issue on Windows 7 & 8 & 8.1

    I think the second solution is cleaner as it's more consistent.

    Thank you for your support.

    Thursday, June 12, 2014 1:21 PM
  • We also had this same issue and chose the option to specify $(DDK_LIB_PATH)\BufferOverflowK.lib in the project properties so that we did not have to manually change the project files and the change was "more visible."  The change "appeared" to work in Windows 7, 8, and 8.1 until recently.  We had a code change go in where our drivers would no longer load under Windows 7 32-bit.  We found that if we changed the TargetVersion to Windows7 in the project files, and reverted the inclusion of $(DDK_LIB_PATH)\BufferOverflowK.lib, then the drivers were able to load on all OSes.  Just an FYI that the one solution may only "appear" to work.
    Saturday, January 31, 2015 12:33 AM