逆向工程 - 在哪里可以找到导致内核模式崩溃的驱动程序的名称？ - 吾爱随笔录

我处于一个有趣的情况。我的 Windows 内核经验非常有限，所以我只是不知道要查找什么数据结构才能找到我需要知道的内容。

有一个驱动程序使我的主机上的 Windows 崩溃。通过检查驱动程序的内存转储，我知道了很多。

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

主要问题：是否可以直接从 Windows（仅限内核）内存转储文件中提取崩溃驱动程序的名称？

如果没有，是否可以通过启用用户模式故障转储来提取该信息（我的意思是用户和内核空间的“活动”故障转储）？

如果可能，我应该在哪里寻找数据结构来找到这些信息？是否有一个方便的 Wdbg 命令可以让我接近？

我的主要目标是检查驱动程序崩溃行为的根本原因，并可能自己重新创建崩溃。