昨天笔者的一位友人联系我，说此前笔者替他组装的一台12代i7的台式机近日频发蓝屏（BSOD）问题，希望笔者能协助他找到问题的原因并解决。

听闻此事后，笔者先让他到设置→系统→关于→高级系统设置→高级→启动和故障恢复设置下，将写入调试信息修改为小内存转储（256K）后，待到下次蓝屏时将蓝屏dump文件发与笔者进行分析。

说明：dump文件类型中相对比较常用的是小内存转储、核心内存转储和完全内存转储这三种，自动内存转储和活动内存转储相对使用遇到，故在此不做特别说明。以下是前三种内存转储文件的区别：

小内存转储：保存内存前64K基本内存空间的数据核心内存转储：保存操作系统和相关系统级别服务的数据完全内存转储：保存内存中包括系统数据和用户数据的全部数据

由于蓝屏问题的发生通常具有突发性和不可预知性，同时为保证能在蓝屏后快速获取并保存内存转储文件进行分析，故在大多数情况下我一般都会设置为小内存转储以保证能得到文件。（完全/核心内存转储文件体积较大，需要相对较长的时间进行转储保存，无法保证能在蓝屏后成功生成文件的可能性较大，尤其是万一遭遇诸如断电等二次灾害的情况）

在得到了友人发来的两个dump文件后，笔者将其载入到WinDbg中进行查看。发现两者都是同样的IRQL_NOT_LESS_OR_EQUAL（中断请求级别不小于或相等）错误，意思是试图在错误的中断级上进行特定操作。

打开第一个文件后，先输入analyze -v命令查看一下大致情况

可以发现错误进程是ntkrnlmp.exe，这是一个和操作系统注册表关联的重要系统进程，看来多半是内存本身或者驱动问题了。为了获取进一步信息，我们使用kv和r命令查看状态。

通过查看调用栈，我们能发现操作系统执行过程中遇到了一个缺页异常，于是系统调用了KiTrapoE异常处理函数来试图处理问题。但执行过程中却发现无法因为找到对应的物理页，所以部署了KiBugCheckEx函数让系统蓝屏。

Windows在调用异常处理函数解决异常时，通常会以生成一个陷阱帧（Trap Frame）的形式保存异常出现时候的现场环境。如果异常被成功解决了，就可以通过定位这个陷阱帧回到异常发生前的线程，恢复正常执行。我们发现这个陷阱帧的地址是ffffb88c到a024f740，因此使用.trap命令切换到陷阱帧：

通过对比查看，我们可以发现，出问题前的最后两个函数是KiRetireDpcList和KiIdleLoop。前者是系统用来扫描DPC请求队列来执行处理机线程切换的函数，后者是用以循环执行DPC检查和堆栈切换的函数。DPC是Windows驱动程序在IRQL DISPATCH_LEVEL上请求回调到任意线程上下文的方法，其需要生成一个DPC对象用以交付内核进行中断级控制。DPC对象的数据结构由LIST_ENTRY、回调指针、回调上下文和控制数据构成。

于是我猜测是否是由于DPC队列越界发生死循环导致的蓝屏？所以接下来我是用db命令查看地址空间。

发现地址空间全是问号，在WinDbg里这说明这些都是无效内容。表示系统无法访问这一部分的内存，因而产生页面异常。使用irql命令查看一下中断级别：

由于Windows系统的页处理只能发生在2以下的中断级别上，因此就会报一个IRQL_NOT_LESS_OR_EQUAL错误。但仅凭这份文件我仍然无法断定问题出在哪。是由哪个进程/驱动程序造成了DPC队列越界，于是我对第二份dump文件进行了同样的分析流程。

和第一份文件一样报的是IRQL_NOT_LESS_OR_EQUAL错误，但是不同之处在于PROCESS_NAME字段中出现了360Tray.exe的字样。

于是我开始怀疑是不是由360造成的问题，接着我再次使用kv;r命令进行检查

发现这次的蓝屏触发更为复杂，一开始是进程死锁导致陷阱帧生成了一次，然后系统调函数来解除死锁，遇上了缺页问题，再次生成陷阱帧处理无果，发送bugcheck蓝屏。

综合两次dmp文件分析，笔者认为比较可能的原因是由于360的某些保护机制导致dpc对象访存进程被拒绝而蓝屏。故我已通知友人先将360相关软件彻底卸载来检查是否可以正常使用。

当然也不能排除是不是由于内存损坏或者内存频率参数等对IMC压力太大导致的访存失败，可惜此类问题不藉由TM5等内存测试软件进行较长时间的烤机无法判断是否稳定。暂时只能先让友人检查XMP参数档位是否为更为稳定的XMP I而非XMP II，再经由之后的使用情况来决定是否需要动内存内存参数或者烤机检查内存稳定性。

P.S.第一次写操作系统内核分析的相关专栏，也是首次在B站投稿。笔者操作系统知识和应用水平堪忧，行文中各类遣词造句恐有不少谬误，还希望大家海涵并提出批评意见。望共同进步，谢谢。