/Where can you find the name of a driver causing a kernel mode crash? (via WindowsKernel.com)
Where can you find the name of a driver causing a kernel mode crash?

Where can you find the name of a driver causing a kernel mode crash? (via WindowsKernel.com)


I am in an interesting situation. I have very limited Windows kernel experience, so I just don’t know what data structure to look for in order to find what I need to know.

There is a driver that is crashing Windows on my host machine. I know this much from examining the memory dump from the driver.

For analysis of this file, run !analyze -v
nt!KeBugCheckEx:
fffff807`4cdc14e0 48894c2408      mov     qword ptr [rsp+8],rcx ss:0018:fffff389`040e6990=00000000000000f7
3: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_OVERRAN_STACK_BUFFER (f7)
A driver has overrun a stack-based buffer.  This overrun could potentially
allow a malicious user to gain control of this machine.
DESCRIPTION
A driver overran a stack-based buffer (or local variable) in a way that would
have overwritten the function's return address and jumped back to an arbitrary
address when the function returned.  This is the classic "buffer overrun"
hacking attack and the system has been brought down to prevent a malicious user
from gaining complete control of it.
Do a kb to get a stack backtrace -- the last routine on the stack before the
buffer overrun handlers and bugcheck call is the one that overran its local
variable(s).
Arguments:
Arg1: fffff389040e69d0, Actual security check cookie from the stack
Arg2: 000041be41f88edc, Expected security check cookie
Arg3: ffffbe41be077123, Complement of the expected security check cookie
Arg4: 0000000000000000, zero

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


KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.Sec
    Value: 1

    Key  : Analysis.DebugAnalysisProvider.CPP
    Value: Create: 8007007e on DESKTOP-GS87ORM

    Key  : Analysis.DebugData
    Value: CreateObject

    Key  : Analysis.DebugModel
    Value: CreateObject

    Key  : Analysis.Elapsed.Sec
    Value: 9

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 64

    Key  : Analysis.System
    Value: CreateObject


BUGCHECK_CODE:  f7

BUGCHECK_P1: fffff389040e69d0

BUGCHECK_P2: 41be41f88edc

BUGCHECK_P3: ffffbe41be077123

BUGCHECK_P4: 0

SECURITY_COOKIE:  Expected 000041be41f88edc found fffff389040e69d0

STACK_TEXT:  
fffff389`040e6988 fffff807`4ce7c485 : 00000000`000000f7 fffff389`040e69d0 000041be`41f88edc ffffbe41`be077123 : nt!KeBugCheckEx
fffff389`040e6990 fffff807`4cc4066c : 00000000`00000000 fffff807`4d21a91b 00000000`00000000 fffff389`040e74c0 : nt!_report_gsfailure+0x25
fffff389`040e69d0 fffff389`040e6960 : fffff389`040e6970 fffff389`040e6980 fffff389`040e6990 fffff389`040e69a0 : nt!NtSetInformationWorkerFactory+0x35c
fffff389`040e6b30 fffff389`040e6970 : fffff389`040e6980 fffff389`040e6990 fffff389`040e69a0 00000000`00000000 : 0xfffff389`040e6960
fffff389`040e6b38 fffff389`040e6980 : fffff389`040e6990 fffff389`040e69a0 00000000`00000000 00000000`00000000 : 0xfffff389`040e6970
fffff389`040e6b40 fffff389`040e6990 : fffff389`040e69a0 00000000`00000000 00000000`00000000 00000000`00000000 : 0xfffff389`040e6980
fffff389`040e6b48 fffff389`040e69a0 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0xfffff389`040e6990
fffff389`040e6b50 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0xfffff389`040e69a0


SYMBOL_NAME:  nt!_report_gsfailure+25

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

STACK_COMMAND:  .thread ; .cxr ; kb

BUCKET_ID_FUNC_OFFSET:  25

FAILURE_BUCKET_ID:  0xF7_MISSING_GSFRAME_nt!_report_gsfailure

OS_VERSION:  10.0.18362.1

BUILDLAB_STR:  19h1_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {82d2c1b5-b0cb-60a5-9a5d-78c8c4284f84}

Followup:     MachineOwner

Main Question: Is it possible to directly extract the name of the crashing driver from a windows (kernel only) memory dump file?

If not, is it possible to extract that information by enabling user mode crash dumps (by this I mean the “active” crash dump with by user and kernel space)?

If it is possible, where should I look for the data structure to find this information? Is there a convenient Wdbg command that will get me close?

My main goal is to examine the root cause of the driver’s crashing behavior and possibly recreate the crash myself.

This is a syndicated post. Read the original post at Source link .