电脑两周没关机，准备关机的时候突然蓝屏，得到错误是

IRQL_NOT_LESS_OR_EQUAL，重启后利用everything搜索*.dmp按时间排序找到生成的内存dump文件利用windbg进行错误分析。

权限问题

一开始直接在源目录中进行分析会导致windbg因为权限问题没法载入dmp文件，直接复制到桌面上进行分析即可

在文件，第一个选项，找到open dump file，直接对dmp文件载入分析即可。

dump一般分类为full dump，即发生报错的时候所有的内存快照，体积较大，信息比较全面。另一种就是minidump，只包含了发生异常时的上下堆栈的环境，适合用来提交报错，比较简单明了，但是并不包含当时的内存转储，一般默认是minidump，也可以改成full dump模式。

载入

一般都是显示上面的一些基本信息，主要就是针对蓝屏时候的堆栈和蓝屏的进程进行分析，并尝试发现问题。

信息分析

6: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: ffffcf07d379a230， memory referenced
Arg2: 0000000000000002， IRQL
Arg3: 0000000000000001， bitfield :
    bit 0 : value 0 = read operation， 1 = write operation
    bit 3 : value 0 = not an execute operation， 1 = execute operation (only on chips which support this level of status)
Arg4: fffff8031391807f， address which referenced memory

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


KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.mSec
    Value: 1483

    Key  : Analysis.DebugAnalysisManager
    Value: Create

    Key  : Analysis.Elapsed.mSec
    Value: 1541

    Key  : Analysis.IO.Other.Mb
    Value: 18

    Key  : Analysis.IO.Read.Mb
    Value: 0

    Key  : Analysis.IO.Write.Mb
    Value: 31

    Key  : Analysis.Init.CPU.mSec
    Value: 530

    Key  : Analysis.Init.Elapsed.mSec
    Value: 131146

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

    Key  : Bugcheck.Code.DumpHeader
    Value: 0xa

    Key  : Bugcheck.Code.Register
    Value: 0xa

    Key  : Dump.Attributes.AsUlong
    Value: 1808

    Key  : Dump.Attributes.DiagDataWrittenToHeader
    Value: 1

    Key  : Dump.Attributes.ErrorCode
    Value: 0

    Key  : Dump.Attributes.KernelGeneratedTriageDump
    Value: 1

    Key  : Dump.Attributes.LastLine
    Value: Dump completed successfully.

    Key  : Dump.Attributes.ProgressPercentage
    Value: 0


FILE_IN_CAB:  061023-11093-01.dmp

DUMP_FILE_ATTRIBUTES: 0x1808
  Kernel Generated Triage Dump

BUGCHECK_CODE:  a

BUGCHECK_P1: ffffcf07d379a230

BUGCHECK_P2: 2

BUGCHECK_P3: 1

BUGCHECK_P4: fffff8031391807f

WRITE_ADDRESS: fffff8031431c468: Unable to get MiVisibleState
Unable to get NonPagedPoolStart
Unable to get NonPagedPoolEnd
Unable to get PagedPoolStart
Unable to get PagedPoolEnd
unable to get nt!MmSpecialPagesInUse
 ffffcf07d379a230 

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXPNP: 1 (!blackboxpnp)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT:  1

PROCESS_NAME:  msedge.exe

TRAP_FRAME:  ffffb58592d6f220 -- (.trap 0xffffb58592d6f220)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=ffffcf07d379a230
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8031391807f rsp=ffffb58592d6f3b0 rbp=ffffb58592d6f749
 r8=0000000000000000  r9=ffffb58592d6f7d8 r10=0000000000000000
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
nt!KiAcquireKobjectLockSafe+0xf:
fffff803`1391807f f00fba2907      lock bts dword ptr [rcx]，7 ds:ffffcf07`d379a230=00060000
Resetting default scope

STACK_TEXT:  
ffffb585`92d6f0d8 fffff803`13a417a9     : 00000000`0000000a ffffcf07`d379a230 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
ffffb585`92d6f0e0 fffff803`13a3ce34     : 00000000`00000001 ffffb585`92d6f7d0 00000000`00000000 00000000`00000001 : nt!KiBugCheckDispatch+0x69
ffffb585`92d6f220 fffff803`1391807f     : 00000000`00000000 fffff803`1383d78a 00000000`00000010 00000000`00050282 : nt!KiPageFault+0x474
ffffb585`92d6f3b0 fffff803`1383d7eb     : ffff910c`f1ded080 ffffcf07`d379a230 00000000`00000000 00000000`00000000 : nt!KiAcquireKobjectLockSafe+0xf
ffffb585`92d6f3e0 fffff803`13bb7df2     : ffff910c`00000001 ffffb585`92d6f749 00000000`00000000 ffffb585`92d6f7d0 : nt!KeSetEvent+0x6b
ffffb585`92d6f470 fffff803`13938673     : 00000000`00000000 00000000`00000001 ffff910c`f1ded080 ffffcf08`3658b750 : nt!PsDispatchIumService+0x96e
ffffb585`92d6f6e0 fffff803`13f589d7     : 00000001`400000d0 ffff910d`135440c0 ffff910d`13544518 00000000`0000000b : nt!VslpEnterIumSecureMode+0x287
ffffb585`92d6f7b0 fffff803`13b893b1     : 00000000`0000000b 00000000`000000a0 00000000`00000000 ffffcf08`2c7978b8 : nt!VslRundownSecureProcess+0x47
ffffb585`92d6f860 fffff803`13eb4315     : ffffcf08`2c7978b0 ffffcf08`2c797860 ffffcf08`2c7978a0 fffff803`13cef7c8 : nt!KeRundownSecureProcess+0x15
ffffb585`92d6f890 fffff803`13cf15ca     : ffff910d`135440c0 ffffcf08`18720060 ffff910d`135440c0 00000000`00000000 : nt!PspRundownSingleProcess+0x224e41
ffffb585`92d6f920 fffff803`13d7c402     : 00000000`00000000 ffff910d`13544001 ffff910c`f1ded0f4 00000018`a0587000 : nt!PspExitThread+0x64e
ffffb585`92d6fa20 fffff803`13a40ee8     : ffff910c`0000169c ffff910c`f1ded080 ffff910d`135440c0 ffff910d`135440c0 : nt!NtTerminateProcess+0xf2
ffffb585`92d6faa0 00007ffe`d968f1d4     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x28
00000018`a0dffb78 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffe`d968f1d4


SYMBOL_NAME:  nt!KiAcquireKobjectLockSafe+f

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

IMAGE_VERSION:  10.0.22621.1778

STACK_COMMAND:  .cxr; .ecxr ; kb

BUCKET_ID_FUNC_OFFSET:  f

FAILURE_BUCKET_ID:  AV_nt!KiAcquireKobjectLockSafe

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {87978629-0a82-b7ad-caa7-eb2c5ba684a3}

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

开头

第一行可以看到报错的错误类型：

后面的(a)代表这个错误的错误代码是0x0000000A，后面是对这个错误的解析

尝试在中断请求级别(IRQL)访问一个可分页(或完全无效)的地址，这个等级太高了。这通常是由于驱动程序访问了错误的地址造成的。

接下来是关于本机这个报错时的四个参数，这来自Windows内核的Bug 检查机制

Bug 检查会显示蓝屏信息，记录关键的Bug 检查代码与参数等信息，并转储内核的内存与寄存器状态。

Arguments:
Arg1: ffffcf07d379a230， memory referenced
// 导致无效访问的内存地址
Arg2: 0000000000000002， IRQL
// 当前的IRQL级别
Arg3: 0000000000000001， bitfield :
    bit 0 : value 0 = read operation， 1 = write operation
    bit 3 : value 0 = not an execute operation， 1 = execute operation (only on chips which support this level of status)
// 无效访问的类型(读/写/执行)
Arg4: fffff8031391807f， address which referenced memory
// 导致此无效访问的调用地址

每个 bug 检查代码都有四个关联的参数，用于提供信息。可以通过windbg中的命令：!analyze -show <error code>来查看

针对每个报错的信息的bug检查代码的参数的解释可以从这里找到：https://learn.microsoft.com/zh-cn/windows-hardware/drivers/debugger/bug-check-code-reference2

可以通过命令!analyze -show <error code> <vaule>来指定第一个参数的值

想显示后面的某一个参数，不能跳，不能用空格代替，直接输入0就行，如下图

本次报错的bug检查函数的四个参数的详细内容在这里：https://learn.microsoft.com/zh-cn/windows-hardware/drivers/debugger/bug-check-0xa--irql-not-less-or-equal

KEY_VALUES_STRING

KEY_VALUES_STRING: 1表示此转储信息包含1组KEY_VALUES_STRING数据。这一组键值表示了发生crash的时候一些环境状况，对于一般分析来说没啥用。

KEY_VALUES_STRING的值提供了此内核转储的相关分析信息和属性。它们代表的意义如下:

Analysis.CPU.mSec: 内核分析使用的CPU时间，单位ms。
Analysis.DebugAnalysisManager: 当前使用的WinDbg分析管理器名称。
Analysis.Elapsed.mSec: 内核分析总耗时，单位ms。
Analysis.IO.Other.Mb: 内核分析过程中的其他IO操作数据量，单位Mb。
Analysis.IO.Read.Mb: 内核分析过程中的读IO操作数据量，单位Mb。
Analysis.IO.Write.Mb: 内核分析过程中的写IO操作数据量，单位Mb。
Analysis.Init.CPU.mSec: WinDbg初始化内核分析使用的CPU时间，单位ms。
Analysis.Init.Elapsed.mSec: WinDbg初始化内核分析总耗时，单位ms。
Analysis.Memory.CommitPeak.Mb: 内核分析过程中内存占用峰值，单位Mb。
Bugcheck.Code.DumpHeader: 转储文件头部记录的Bug 检查代码，0xa代表IRQL_NOT_LESS_OR_EQUAL。
Bugcheck.Code.Register: 寄存器记录的Bug 检查代码，0xa代表IRQL_NOT_LESS_OR_EQUAL。
Dump.Attributes.AsUlong: 转储文件的属性值。
Dump.Attributes.DiagDataWrittenToHeader: 转储文件头部是否包含诊断数据，1表示包含。
Dump.Attributes.ErrorCode: 转储产生的错误代码，0表示无错误。
Dump.Attributes.KernelGeneratedTriageDump: 是否由内核生成的修复转储，1表示是。
Dump.Attributes.LastLine: 转储操作的最后一行结果，这里显示转储成功完成。
Dump.Attributes.ProgressPercentage: 转储文件头部记录的转储操作进度百分比，此处未记录。

FILE_IN_CAB

FILE_IN_CAB: 061023-11093-01.dmp表示此转储文件原来包含在名为061023-11093-01.cab的CAB压缩包中。

在Windows故障转储的传输和处理过程中，多个转储文件通常被压缩成.cab格式的压缩包进行传输，以减小文件大小，便于传输和存储。一旦需要分析其中的某个转储文件，会先从.cab压缩包中将其提取出来，然后加载到WinDbg等转储分析工具中进行分析。

所以这行信息，是WinDbg在加载此转储文件时，从转储文件本身提取的元数据，它记录了此转储文件原来打包在名为061023-11093-01.cab的CAB压缩包中的事实。

对于分析来说没有实际意义。

DUMP_FILE_ATTRIBUTES

DUMP_FILE_ATTRIBUTES: 0x1808

表示此转储文件的属性值为0x1808。

0x1000: 内核生成的修复转储(Kernel Generated Triage Dump) 0x0800: 包含诊断数据的转储文件头 0x0008: 转储操作成功完成

所以关于这个特性的解释就是：

此转储文件属于内核生成的修复转储(Kernel Generated Triage Dump)
此转储文件的头部包含诊断数据
此转储操作成功完成

没啥用处，就是告诉你在生成这个转储文件的时候很成功，没有发生意外和中断。

这下面的几个BUGCHECK和前面最开始展示的四个参数是一个东西

就是分开说了一下，没啥用。

再往下就是这个信息，这个信息主要是windbg在分析此转储文件时,尝试从转储获取一些重要的内存布局信息失败了,所以无法确定地址fffffcf07d379a230是否属于可写内存区域。

WRITE_ADDRESS: fffff8031431c468: 
Unable to get MiVisibleState    //可见内存页的状态信息
Unable to get NonPagedPoolStart    //非分页内存池的起始和结束地址
Unable to get NonPagedPoolEnd    
Unable to get PagedPoolStart    //分页内存池的起始和结束地址
Unable to get PagedPoolEnd
unable to get nt!MmSpecialPagesInUse    //正在使用的特殊内存页信息
 ffffcf07d379a230

由于获取这些信息失败,所以WinDbg无法判断地址fffffcf07d379a230是否可写,只能输出一条警告信息。

一般在下面三种情况下会发生这种情况，2比较常见的可能。

此转储已损坏,关键内存布局信息丢失或损坏
此转储属于修复转储或转储级别较低,未包含上述信息
系统内存布局发生变化,WinDbg版本较旧无法正确解析

BLACKBOXBSD

BSD/BSOD

Berkeley Software Distribution或Berkeley Standard Distribution的缩写，一般是FreeBSD等操作系统的简称，这里指的是Blue screen of death

这3条信息表示WinDbg加载了黑箱扩展(BlackBox Extension)来分析此转储文件。

BLACKBOXBSD: 1 (!blackboxbsd)

加载了 blackboxbsd.dll 扩展来分析BSD磁盘子系统相关的问题。

BLACKBOXNTFS: 1 (!blackboxntfs)

加载了 blackboxntfs.dll 扩展来分析NTFS文件系统相关的问题。

BLACKBOXPNP: 1 (!blackboxpnp)

加载了 blackboxpnp.dll 扩展来分析即插即用(PnP)与电源管理相关的问题。没啥用，除非你超频了

黑箱扩展由微软提供,包含许多专门用于分析Windows内核和驱动程序相关子系统的脚本与工具。通过加载不同的黑箱扩展,WinDbg可以自动进行驱动和系统服务相关的分析来查找潜在问题。这里可以直接点击后面的命令查看不同的详细信息。

报错进程和次数

这是关键的部分，它直白的告诉你是哪里发生的报错和这是第几次发生的报错

本机报错是由msedge.exe进程导致的，这是edge浏览器的主进程，这正好对应了我在关闭浏览器时发生蓝屏的时间节点。

寄存器状态

trap frame

无论3环是从中断门还是systementer进入0环，3环的寄存器都会寄存在_Trap_Frame结构体中，通过命令dt _KTrap_Frame可以从windbg中查看该结构体

6: kd> dt _KTrap_Frame
nt!_KTRAP_FRAME
   +0x000 P1Home           : Uint8B
   +0x008 P2Home           : Uint8B
   +0x010 P3Home           : Uint8B
   +0x018 P4Home           : Uint8B
   +0x020 P5               : Uint8B
   +0x028 PreviousMode     : Char
   +0x028 InterruptRetpolineState : UChar
   +0x029 PreviousIrql     : UChar
   +0x02a FaultIndicator   : UChar
   +0x02a NmiMsrIbrs       : UChar
   +0x02b ExceptionActive  : UChar
   +0x02c MxCsr            : Uint4B
   +0x030 Rax              : Uint8B
   +0x038 Rcx              : Uint8B
   +0x040 Rdx              : Uint8B
   +0x048 R8               : Uint8B
   +0x050 R9               : Uint8B
   +0x058 R10              : Uint8B
   +0x060 R11              : Uint8B
   +0x068 GsBase           : Uint8B
   +0x068 GsSwap           : Uint8B
   +0x070 Xmm0             : _M128A
   +0x080 Xmm1             : _M128A
   +0x090 Xmm2             : _M128A
   +0x0a0 Xmm3             : _M128A
   +0x0b0 Xmm4             : _M128A
   +0x0c0 Xmm5             : _M128A
   +0x0d0 FaultAddress     : Uint8B
   +0x0d0 ContextRecord    : Uint8B
   +0x0d8 Dr0              : Uint8B
   +0x0e0 Dr1              : Uint8B
   +0x0e8 Dr2              : Uint8B
   +0x0f0 Dr3              : Uint8B
   +0x0f8 Dr6              : Uint8B
   +0x100 Dr7              : Uint8B
   +0x0d8 ShadowStackFrame : Uint8B
   +0x0e0 Spare            : [5] Uint8B
   +0x108 DebugControl     : Uint8B
   +0x110 LastBranchToRip  : Uint8B
   +0x118 LastBranchFromRip : Uint8B
   +0x120 LastExceptionToRip : Uint8B
   +0x128 LastExceptionFromRip : Uint8B
   +0x130 SegDs            : Uint2B
   +0x132 SegEs            : Uint2B
   +0x134 SegFs            : Uint2B
   +0x136 SegGs            : Uint2B
   +0x138 TrapFrame        : Uint8B
   +0x140 Rbx              : Uint8B
   +0x148 Rdi              : Uint8B
   +0x150 Rsi              : Uint8B
   +0x158 Rbp              : Uint8B
   +0x160 ErrorCode        : Uint8B
   +0x160 ExceptionFrame   : Uint8B
   +0x168 Rip              : Uint8B
   +0x170 SegCs            : Uint2B
   +0x172 Fill0            : UChar
   +0x173 Logging          : UChar
   +0x174 Fill1            : [2] Uint2B
   +0x178 EFlags           : Uint4B
   +0x17c Fill2            : Uint4B
   +0x180 Rsp              : Uint8B
   +0x188 SegSs            : Uint2B
   +0x18a Fill3            : Uint2B
   +0x18c Fill4            : Uint4B

借用csdn中的一位博主的图片：我是win11 64位的，这个图片环境未知，所以有些出入。

这里记录的是发生错误的时候寄存器的状态，其中蓝色的字体Some register values may be zeroed or incorrect.证明了这个dump发生在低等级下，所以寄存器的值并不是全的，内核未能捕获全部寄存器状态。

rip和栈信息(rsp、rbp)是我们判断崩溃原因最关键的信息。我们可以通过rip找到导致崩溃的指令,通过栈桢回溯调用过程。其他寄存器的值也可能提供一定上下文信息帮助分析。

下面还有一行奇怪的玩意：

iopl=0 nv up ei pl zr na po nc

是此trap frame提供的CPU状态标志信息。

其中,每个标志的含义如下：

iopl - I/O特权级,0表示处于用户模式 nv - 溢出标志 up - 协处理器使用标志 ei - 中断使能标志 pl - 特权级标志,0表示处于特权级0 zr - 零标志 na - 辅助进位标志 po - 奇偶标志 nc - 进位标志

这些标志描述了CPU在发生trap时的状态与模式。其实这就是哪些ZF OF寄存器的另一种表示方式。

OV = OVerflow, NV = No oVerflow. DN = DowN, UP (up).

EI = Enable Interupt, DI = Disable Interupt.

NG = NeGative, PL = PLus; a strange mixing of terms due to the

fact that 'Odd Parity' is represented by PO (rather than

POsitive), but they still could have used 'MI' for MInus.

ZR = ZeRo, NZ = Not Zero.

AC = Auxiliary Carry, NA = Not Auxiliary carry.

PE = Parity Even, PO = Parity Odd. CY = CarrY, NC = No Carry.

此trap发生于用户模式(iopl=0, pl=0)
没有溢出或进位(nv=0, nc=0)
没有使用FPU(up=0)
中断已使能(ei=1)
当前无零结果(zr=0)

所以,这些标志信息可以辅助判断导致此trap的代码在什么模式下执行的。但是看这里只是给出了寄存器，但是没有数值，应该是内核并没有进行保存。

崩溃时的指令

这里给出了定位到汇编粒度的位置，这条信息的代表了，在执行到ntoskrnl.exe中的KiAcquireKobjectLockSafe函数偏移位置为0xf的指令lock bts dword ptr [rcx],7 ds:ffffcf07d379a230=00060000的时候，发生的报错（f00fba2907是这个指令的字节码）。

这里代码的具体含义是：以互斥方式修改内存地址ffffcf07`d379a230的第7位。然后就发生了crash。

堆栈信息

这里的堆栈信息显示的是栈回溯信息，可以看到直到发生报错的时候，当前栈上的调用链。它反映了错误堆栈的调用情况。程序执行顺序是从下面往上面走的，可以看到最上面的函数是KeBugCheckEx。

STACK_TEXT:  
ffffb585`92d6f0d8 fffff803`13a417a9     : 00000000`0000000a ffffcf07`d379a230 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
ffffb585`92d6f0e0 fffff803`13a3ce34     : 00000000`00000001 ffffb585`92d6f7d0 00000000`00000000 00000000`00000001 : nt!KiBugCheckDispatch+0x69
ffffb585`92d6f220 fffff803`1391807f     : 00000000`00000000 fffff803`1383d78a 00000000`00000010 00000000`00050282 : nt!KiPageFault+0x474
ffffb585`92d6f3b0 fffff803`1383d7eb     : ffff910c`f1ded080 ffffcf07`d379a230 00000000`00000000 00000000`00000000 : nt!KiAcquireKobjectLockSafe+0xf
ffffb585`92d6f3e0 fffff803`13bb7df2     : ffff910c`00000001 ffffb585`92d6f749 00000000`00000000 ffffb585`92d6f7d0 : nt!KeSetEvent+0x6b
ffffb585`92d6f470 fffff803`13938673     : 00000000`00000000 00000000`00000001 ffff910c`f1ded080 ffffcf08`3658b750 : nt!PsDispatchIumService+0x96e
ffffb585`92d6f6e0 fffff803`13f589d7     : 00000001`400000d0 ffff910d`135440c0 ffff910d`13544518 00000000`0000000b : nt!VslpEnterIumSecureMode+0x287
ffffb585`92d6f7b0 fffff803`13b893b1     : 00000000`0000000b 00000000`000000a0 00000000`00000000 ffffcf08`2c7978b8 : nt!VslRundownSecureProcess+0x47
ffffb585`92d6f860 fffff803`13eb4315     : ffffcf08`2c7978b0 ffffcf08`2c797860 ffffcf08`2c7978a0 fffff803`13cef7c8 : nt!KeRundownSecureProcess+0x15
ffffb585`92d6f890 fffff803`13cf15ca     : ffff910d`135440c0 ffffcf08`18720060 ffff910d`135440c0 00000000`00000000 : nt!PspRundownSingleProcess+0x224e41
ffffb585`92d6f920 fffff803`13d7c402     : 00000000`00000000 ffff910d`13544001 ffff910c`f1ded0f4 00000018`a0587000 : nt!PspExitThread+0x64e
ffffb585`92d6fa20 fffff803`13a40ee8     : ffff910c`0000169c ffff910c`f1ded080 ffff910d`135440c0 ffff910d`135440c0 : nt!NtTerminateProcess+0xf2
ffffb585`92d6faa0 00007ffe`d968f1d4     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x28
00000018`a0dffb78 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffe`d968f1d4

可以将上面的数据分为4栏，最后一栏是函数的符号名称，可以看到基本都是在nt里的函数，都定位到了一些偏移的具体位置；中间一栏是函数的四个参数，用空格隔开。

这个可以通过k命令或者kb命令来看得到类似的结果。

结尾



SYMBOL_NAME:  nt!KiAcquireKobjectLockSafe+f
# 发生报错的符号名称（函数名称）
MODULE_NAME: nt
# 发生报错的模块名称，这里是内核
IMAGE_NAME:  ntkrnlmp.exe
# 发生错误的镜像名称
IMAGE_VERSION:  10.0.22621.1778
# 映像的版本号
STACK_COMMAND:  .cxr; .ecxr ; kb
# 一些命令
BUCKET_ID_FUNC_OFFSET:  f
# 对应发生报错地址的函数里的偏移
FAILURE_BUCKET_ID:  AV_nt!KiAcquireKobjectLockSafe
# 显示此问题的唯一桶ID
OSPLATFORM_TYPE:  x64
# 系统位数
OSNAME:  Windows 10
# 系统名称，我是win11，内核版本还是win10
FAILURE_ID_HASH:  {87978629-0a82-b7ad-caa7-eb2c5ba684a3}
# 对应这个错误的hash值
Followup:     MachineOwner
---------

总结

使用windbg对dump文件进行分析，关键就是一个映像的名称，报错信息，进程名称还有一个堆栈信息，一般如果是Windows自己的程序和应用和内核发生了错误基本就无解了，比如这个dump文件显示的内容。

这个分析主要是对dump里显示的内容的每一个条目的原理和内容进行学习，主要是偏重于内容的分析解释而不是操作的过程。

蓝屏 - windbg模块解析