随后会显示选择进程对话框，可以在里面找到崩溃的进程。选定之后，WinDbg把他打开，显示一个跟打开转储文件差不多的界面。两者的区别是：当你打开转储文件时，可以执行!analyze命令，这个命令能启发式地分析出崩溃的原因，而在你附到一个进程的时候，这个命令只能告诉你由一个调试程序附到了这个进程上：

　　  我注意到在列表的顶部有很多函数名字里带“Exception“。顺着列表往下看（堆栈的上部），我看到Nvappfilter中一个被称作”Kernel32.dll的HeapFree函数“的函数，接着进程便崩溃了。堆释放例行程序中的例外意味着要么调用程序传递了一个错误的堆地址，要么在函数执行的时候堆已经被破坏了。如果调用程序是一个Windows DLL我会怀疑是后一个原因，但是在这种情况下，调用程序是一个第三方的DLL（之所以知道是第三方DLL是因为WinDbg找不到它的符号信息，也就不知道里面的函数的名字）。我使用lm（列出模块）命令找出了关于它的版本信息，从而确认了这一点：

 

 

    Nvappfilter现在是首要嫌疑，但我现在还缺乏直接证据。我继续运行系统，然后用相同的方法分析了后面的几次崩溃。不管是IE、WMP或是游戏，出错的堆栈都是相同的，都是Nvappfilter调用HeapFree。这虽然不能作为决定性的证据，但是作为旁证已经很足够了。

    我随后上网查找看有没有Nvappfilter 的升级，但是我并不知道Nvappfilter 在哪一个软件包中。我把它输入搜索引擎，发现它是nVidia的FirstPacket功能的一部分。 FirstPacket被用来提高游戏的网络通信的优先级，是nForce主板自带软件的一部分：

   

 

    我到nVidia的网站上去下载了一份最新的nForce驱动程序，但是Nvappfilter.dll并没有更新，所以我还是得忍受程序崩溃。nVidia控制面板没有什么选项可以阻止Nvappfilter的载入，所以我只能手动把他禁用。我并不使用FirstPacket，因为我之前根本不知道这个功能，但是我要搞清楚它是怎么样让Windows加载它的。所以我转而求助于Autoruns，随后在Winsock Layered Service Provider (LSP)部分找到了对Nvappfilter 32位版和64位版的引用：

   

 

    我把和Nvappfilter 有关的项目都删掉了，重启系统然后直到现在也没有程序崩溃的情况发生。我在写这篇文章的时候又去看了一下nForce 的驱动程序有没有更新Nvappfilter。最新的驱动程序好像已经不再包含Nvappfilter 或者其他的Winsock LSP，所以就算是Nvappfilter引起的故障，现在也不成问题了。

    在研究这些崩溃的时候我还做了另外一件事就是好好的利用了Vista SP1的“本地转储“功能，它可以在程序崩溃的时候自动生成转储文件供我研究。只要新建一个注册表键HKLM\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps，WerFault就会帮你生成”本地转储“了。默认情况下转储文件被放在%LOCALAPPDATA%\Crashdumps，不过你也可以利用注册表键值修改默认位置，还能指定WerFault保留多少分转储文件。