太惨了！蓝屏了，我的文章没了

在某一个平行宇宙中，各位读者大大现在看到的应该是一篇关于网络协议的文章。

这个平行宇宙与当前宇宙的分叉点来源于2个小时前，我点了一下Wireshark抓包，一刹那，蓝屏了，那篇文章中近一段时间写的内容没了。

我差点拍案而起，WTF！保存啊保存，一个不留神就忘记了。

事情是这样的：

我想抓一些DHCP协议的数据包，于是将网卡禁用，然后开启Wireshark，打算把一会儿启用网卡后的通信过程抓下来。然而等我双击网卡开始抓包的一瞬间，蓝了！

捶足顿胸之际，不小心瞅见了蓝屏界面上蓝屏的驱动程序名字：npcap.sys，看来是Wireshark用的抓包驱动有问题呀！

这家伙害我害得这么惨，我不打算放过它，决定找出来到底这程序哪里写的有问题。

等了几分钟，电脑重启后，在C:\Windows目录下找到了系统崩溃后产生的核心存储文件：MEMORY.dmp，这个文件是操作系统崩溃后，Windows将内核的数据、所有进程、线程的执行上下文进行了保存，相当于对“案发现场”进行了“拍照”，用于事后定位问题。

注意，这个得提前设置好才会存储，默认情况下只会存储一个很简单的mini dump文件，不利于问题分析。

祭出内核分析神器：WinDbg，来加载分析dump文件。

因为已经知道崩溃位置位于npcap.sys文件，所以先去简单了解了一下这个东西。

Linux上咱们使用tcpdump抓取数据包时，底层使用的核心库就是libpcap，这是一个开源项目，在Windows上对应的就是winpcap。后来在Win7之后，Windows上使用了更现代化的抓包接口，Wireshark默认使用npcap来代替了传统的winpcap。

既然是开源项目，事情就好办了，有源码，有PDB符号文件。

源码大家知道，PDB文件可能有些人不知道。我们知道C/C++这类语言编译完成后，所有的函数名字、参数、数据结构定义等信息就丢失了，剩下的都是CPU指令了。那万一程序出了问题程序员怎么分析呢？这就需要pdb文件了，pdb是程序数据库的意思，这里面有前面说的那些信息。

在npcap项目的官网，找到了npcap.sys驱动程序对应版本的npcap.pdb文件，下载后，载入WinDbg中，可以看到程序崩溃的函数调用堆栈：

看到了吧，有了PDB文件，连源代码路径都显示出来了。

在GitHub上找到了这个openclos.c文件，定位到最后导致崩溃的函数：NPF_FreeCapData

具体是崩溃在哪一行呢？

回头看看windbg可以告诉我们具体那一行指令的地址，在上下文的RIP寄存器中可以看到：

看一下这个位置的指令是个啥：

导致蓝屏的是这一条指令：

mov rbx, [rdx+18h]

这条指令的意思是把rdx+18指向位置的内容，读取到rbx寄存器中。又看了一下崩溃代码是内存访问异常，那肯定就是rdx+18这个地址有问题了。

地址有问题，那现在rdx是个啥呢？

我去，居然是0，空指针NULL啊！那不崩溃就怪了！

结合汇编指令和数据结构定义，就能锁定源码中的具体位置了：在源码中的三级指针访问中，第二级指针的pNBLCopy字段为空！而代码中又没有判断为空指针的情况，就崩溃了～

再次结合函数调用栈和GitHub中的源代码，可以看到这是在清理释放抓取到的所有数据包时出现的问题，看下面代码，这是在一个循环中，挨个释放每个数据包所占据的资源，所有数据包以双链表形式串联了起来。

问题分析到这里，我已经按捺不住心里的激动了，难道我发现了一个0day漏洞？要知道，驱动程序空指针bug用的好可是能做内核级攻击的！一个漏洞都是值不少$的。

刚刚幻想了1秒钟，马上清醒过来，等等，我这版本好像不是最新的，我康康最新的版本还有没有这个问题。

结果泼了我一盆冷水，新的版本，已经增加了对这个指针是否为空的判断了：

哎！与财富擦肩而过～