有同事在客户现场遇到了蓝屏问题，分析和很久没有结论，请求我帮忙分析一下DUMP文件，本文记录一下整个分析过程。

1. 背景

有电脑频繁出现蓝屏，蓝屏代码为DRIVER_POWER_STATE_FAILURE，例如如下：

从现场反馈，好像是每次在开机的时候出现蓝屏，接下来我们具体分析一下这个问题的原因。

2. 分析

首先，我们看蓝屏时候出现的堆栈信息：

从上面我们可以大致的猜测到是因为在处理PNP电源消息的时候超时了，然后被看门狗检测到了操作超时而引发的蓝屏，这里我们不去纠结看门狗这个机制，存在的问题肯定是超时导致的，我看看下PNP LOCK对应的栈信息：

这里看到了system进程中存在一个线程等待NDIS的事件信号，并且从这个堆栈中我们大致发现这个线程应该占用了PNP锁，我们看下占用情况：

确实仿佛是wininit在关机的时候（跟客户反馈的开机似乎有点不一样，但是这里并不影响分析过程），请求占用设备栈的锁，然后陷入了等到状态，等待的锁被上面的线程栈调用给占用了。

我们继续分析这个线程

从中，我们找到等待的事件

但是我们从这个事件已经无法发现很多有用的东西了。不过我们从WaitListHead [Type: _LIST_ENTRY]我们可以知道，到底我多少个线程在等待这个事件，遍历所有线程链表如下：

这里看到了一个可疑的线程：

这个线程虽然比较可疑，但是似乎他并没有占用什么资源导致等待，先认定他是可疑的点吧。

我们从事件的源头出发，查看导致等待的代码

确实存在等待一个事件的操作，验证了我们上面的分析过程，我们看下这个事件在哪些地方可以设置，通过查找我们发现了两个地方

还有就是void __fastcall Ndis::BindEngine::UpdateBindings(Ndis::BindEngine *this, struct KLockThisExclusive *a2)这个函数

明显第一个是没有什么可以分析的了，因为第一个是构造函数，构造函数肯定调用的，并且调用完成构造函数之后，事件是有信号的，那么这里我们可以得到一个分析的点，那么谁把这个事件状态clear掉了呢？

接着分析我们发现

就在void __fastcall Ndis::BindEngine::UpdateBindings(Ndis::BindEngine *this, struct KLockThisExclusive *a2)这个函数的上层调用了Clear操作，等等到了这里我们看一下那个可疑的调用操作

刚好在这个调用过程中了，那么看来这是这个调用无疑了，我们看下这个IRP操作：

那么大致是NdisOpenAdapter调用的时候出现了错误了，本人对于Ndis驱动没有过多深入的研究，也不知道这个调用是否真会造成问题。

但是我们大致可以得到结论，卡死蓝屏应该就是这个驱动导致的。

3. 验证

让同事将这个驱动重命名，测试蓝屏不再重现，因此基本得出结论，就是这个驱动错误导致蓝屏。