家用电脑用什么防火墙比较好？

楼主可以看看这个，参考一下。
流氓软件和木马在各种防火墙和杀毒软件的“打压”之下已经开始逐步向内核“退缩”，传统的依靠查看本地打开的端口与进程的关系的方法检查非法网络访问已经不再适用，个人防火墙已经成为装机必备的软件。目前主流的个人防火墙软件都是构建在Windows内核之上的，但是Windows的内核驱动是分层的，防火墙工作在哪一层实际上就决定了防火墙的性能，工作在TDI层的防火墙是无论如何也不能知道NDIS层的数据收发情况的，因为TDI驱动层在内核中是高于NDIS驱动层的。过去的木马（上个世纪九十年代以前）都是构建在Windows应用层上的普通程序，工作在TDI层的防火墙可以轻易地觉察并阻断它们非法的网络访问，但是对付缩进内核的木马和流氓软件，单纯的依靠TDI层拦截已经显得力不从心。内核木马的特点是不依赖句柄，不绑定端口（NDIS）
)，可以工作在TDI层，甚至在NDIS层，所以，真正可靠的防火墙应该在NDIS层建立防线。
虽然真正可靠的防火墙应该工作在NDIS层，但是，个人防火墙和用于服务器的防火墙毕竟还是有一些不同之处，工作在服务器端的防火墙只需要根据协议、地址和端口判断是转发还是丢弃就行了，高级一点还可以分析包内容，根据预设的专家系统判断是正常的数据包还是非法攻击数据包，这样的防火墙还可以用硬件实现。但是个人防火墙的特别之处就是需要与用户交互，用户数据多是基于IP协议的，并且用户并不关心协议的细节（掌握这些对大多数用户来说有点难度），所以个人防火墙除了通过IP层的协议进行过滤之外，更主要的手段是根据用户的意愿允许还是阻止某个进程（程序）访问网络，在这个粒度上用户比较容易理解和控制。从这一点上讲，工作在TDI层的防火墙的优势就是能够在网络访问发生的时候追踪到发起访问的进程名称，从而给用户一个提示，而工作在NDIS层的防火墙则不容易做到这一点。因为发送数据时上层驱动将数据包提交到NDIS的发送队列中后就返回了，当数据包被真正投递的时候已经无从确定是哪个程序（进程）发送的了，对于收到的数据包需要根据端口号判断是哪个程序的，但是在NDIS层并不知道端口号和进程的对应关系，所以无论数据发送还是接收都无法有效地确定是属于哪个进程的数据。如果不能确定哪个进程访问网络，只是根据地址、端口和协议进行过滤对（大多数）用户来说是很不友好的，所以最好的个人防火墙（不一定是最安全的）应该是TDI＋NDIS双保险：TDI层根据进程级访问过滤，NDIS层根据地址、端口和协议过滤。
前几天，一个朋友要我给他推荐一款比较好的防火墙软件，说实话，我也不知道哪个好，因为我没有比较过。没有调查就没有发言权，随便应付也不是本人的风格，加上本人最近正在验证一个在内核构建TCP/IP协议绕过防火墙的概念的可行性，需要对当前主流防火墙的能力有所了解，所以就把当前比较流行的防火墙都弄来研究了一下，没想到真是大开眼界，不看不知道，一看吓一跳。先上网搜了一下个人防火墙，没想到有这么多种，没时间全搞一遍，只能对用的最多的几个下手了，它们是“天网防火墙个人版”，“金山网镖”，“瑞星个人防火墙”，“卡巴斯基”，“冰盾”和“风云防火墙”，有几个防火墙软件不仅提供网络防火墙功能，还提供诸如文件访问控制，进程创建保护等功能，不过本文只是比较它们的网络防范功能。
首先是天网防火墙，这可是本人上学的时候最喜欢的防火墙了，简单好用。这次使用的是天网防火墙个人版（Trial_Release_v30_Build1213），结果却令人失望，天网是一个单纯的TDI防火墙。下图天网启动后的设备驱动加载情况：
图 1 天网防火墙设备驱动加载情况
工作在TDI层的防火墙有两种方式，一种是做成过滤驱动挂接到支持TCP/IP协议的设备上，简单地讲，就是发送给TCP/IP协议驱动的请求会先发送给它过滤，另一种是使用Hook的方式直接HookTCP/IP协议的驱动分派函数，相比较而言，第一种比较容易bypass，驱动层的木马或流氓软件通过设备直接找到TCP/IP的驱动发送请求，就可以避开Attach在其上的过滤驱动，从上图看，天网的驱动是一个Filter驱动，除了直接向TCP/IP的驱动发送请求可以避开天网之外，还有一种方法可以让它完全失效，就是直接摘除挂接的Filter驱动，看看下面的代码：
void ByPassAttachDevice(PDEVICE_OBJECT DeviceObject)
{
PDEVICE_OBJECT CurDevObj = DeviceObject;

while(CurDevObj != NULL )
{
CurDevObj->AttachedDevice = NULL;
CurDevObj = CurDevObj->NextDevice;
}
}
运行在驱动层的木马只要对设备驱动运行一下ByPassAttachDevice()函数就可以让天网和所有使用这种技术的防火墙形同虚设。口说无评，本人专门写了一个驱动来验证，首先在天网的设置中禁止IE访问网络，此时IE的网络访问会被禁止：
图 2 天网防火墙组织IE访问网络
然后用驱动加载测试工具加载本人编写的驱动程序（文后附有加载工具和驱动程序，以及使用说明，可以用来测试一下你用的防火墙是否安全），假设这是一个运行在内核的木马或流氓软件：
图 3 加载Bypass驱动程序
运行后天网就失效了，看看IE可以访问网络了，不仅IE，所有被禁止的程序都可以访问网络了：
图 4 天网防火墙失效了
结论，就不说了，真的很失望。
下面看看金山网镖，这个是我的朋友很喜欢用的，一直说它好用，本次比较用的是金山安全套件2008中附带的金山网镖，先看看它的驱动加载情况：
图 5 金山网镖驱动加载情况
这也是一个TDI Filter，没有在NDIS层做工作，使用前面的工具可以轻松bypass，不说了，下一个。
接下来是瑞星个人防火墙，使用的版本是瑞星个人防火墙2008。瑞星的驱动在TDI层使用了不容易bypass的TDI hook，除此之外，在NDIS层也使用了Hook，先看看TDI层的情况：
图 6 瑞星驱动的TDI Hook情况
再看看在NDIS层的Hook情况：
图 7 瑞星驱动的NDIS Hook情况
从驱动上看瑞星防火墙要比前两个强很多，本人曾试着手工恢复被hook的函数，虽然恢复后不再d出“某某程序要访问网络”的提示，但是实际上还是不能访问网络，不知为何，有兴趣的朋友可以研究一下。
再来看看卡巴斯基，这次使用的是卡巴斯基的互联网安全套装60个人版，从驱动上看卡巴斯基采用的是用TDI Filter驱动＋NDIS Hook：
图 8 卡达斯基的驱动加载情况
但是可能卡巴斯基的NDIS Hook只是用来分析可以的数据才使用的，也或者是为实现其它功能设置的Hook，总之，使用本文的程序可以bypass卡巴斯基的防火墙功能。
再看看冰盾防火墙，冰盾是一个服务器防火墙，这次使用的是冰盾81 Build60214，从驱动加载情况看，冰盾使用了一个NDIS中间层驱动，没有Hook，也没有处理TDI层的事务，毕竟它不是个人防火墙，没必要处理TDI层的事情（这只是本人的看法的）。工作在NDIS层的好处是可以探测工作在TDI层的rootkit木马，但是对于个人计算机用户来说，冰盾的设计不太好用（或者说比较难理解，相对于其它几种防火墙软件），另外，中间层驱动还容易被Hook，rootkit木马可以Hook它的处理函数，比如指向一个空函数，就可以瘫痪中间层驱动。
最后一个是风云防火墙，这个是从网上搜到的，以前没听说过，使用的版本是V126 正式版。这个软件除了防火墙功能之外，还有很多附加功能，比如文件访问监控，注册表访问监控等等，不过其网络防火墙这块使用的策略和卡巴斯基一样，可以被本文的工具bypass
从分析的结果来看，这几款防火墙软件对于应用程序的访问控制都是没有问题的，但是对于同样工作在内核级别上的木马和流氓软件则问题很多，只有瑞星防火墙结果好一点，其它的几款防火墙软件都挺令人失望，特别是天网防火墙。最后需要强调一点的是即使是瑞星这样使用TDI Hook + NDISHook的方式也不一定就是安全的，因为在应用程序级别上进行网络访问控制还是粒度太粗，如果使用rootkit工具将木马注入到防火墙允许访问网络的程序的进程中，就可以在防火墙眼皮底下堂而皇之地访问网络了，比如IE的一些BHO插件就是这么干得。
驱动加载测试工具以及bypass驱动下载
附录： 驱动加载测试工具以及bypass驱动的使用方法
首先将hook_testsys复制到windows的系统驱动程序目录中（如果是windowsxp的系统，这个目录可能是c:\windows\system32\drivers），然后运行drv_testexe，在驱动文件位置中填入驱动文件hook_testsys的完整路径名，在驱动名称中填入驱动名称，这个比较重要，因为后面的启动、停止和卸载驱动都需要这个驱动名称，不过不一定是“hook_test”，显示名称随便填写就行了。输入完成后首先点击“安装驱动”按钮安装驱动，如果没有错误再点击“启动驱动”按钮启动这个驱动程序，然后就可以测试你的防火墙软件了。测试的方法很简单，就是运行一个访问网络的程序，如果防火墙有效，会提示是否阻止程序访问网络，如果防火墙失效，则没有任何提示，卸载驱动先点击“停止驱动”按钮，然后点击“卸载驱动”按钮就可以了。
orbit 发表于CSDN 2008-04-02 20:46:10

蓝屏死机(Blue Screen of Death,缩写为:BSoD)，指的是微软Windows *** 作系统在无法从一个系统错误中恢复过来时所显示的屏幕图像。
◆错误分析:通常是由有问题的驱动程序引起的(比如罗技鼠标的Logitech MouseWare 910和924版驱动程序会引发这个故障) 同时,有缺陷的内存、 损坏的虚拟内存文件、 某些软件(比如多媒体软件、杀毒软件、备份软件、DVD播放软件)等也会导致这个错误
◇解决方案:检查最新安装或升级的驱动程序(如果蓝屏中出现"acpisys"等类似文件名, 可以非常肯定是驱动程序问题)和软件; 测试内存是否存在问题; 进入"故障恢复控制台", 转到虚拟内存页面文件Pagefilesys所在分区, 执行"del pagefilesys"命令, 将页面文件删除; 然后在页面文件所在分区执行"chkdsk /r"命令;进入Windows后重新设置虚拟内存如果在上网时遇到这个蓝屏, 而你恰恰又在进行大量的数据下载和上传(比如:网络游戏、BT下载), 那么应该是网卡驱动的问题, 需要升级其驱动程序WinDbg是免费软件，其微软官方下载地址参考扩展阅读，具体项目为Install Debugging Tools for Windows 32/64-bit Version。
使用WinDbg分析崩溃时的内存转储文件的前提是您要让系统在崩溃时自动生成一个内存转储文件，做法如下：
1、单击开始，然后单击运行。
2、键入 control sysdmcpl
复制代码
，然后单击确定。您将会打开系统属性，请切换到高级选项卡。结果如下图所示：
3、在高级选项卡上，在启动和故障恢复部分中单击设置。这将打开启动和故障恢复对话框，如下图所示：
4、在写入调试信息列表中，选择“小内存转储(64 KB)”或“核心内存转储”，这样系统在崩溃时将会自动生成对应的内存转储文件。如果您不想让蓝屏只闪烁一下，而是想看清楚它直到您手动重新启动计算机，请清除系统失败部分中自动重新启动(R)项目前的复选框。然后单击确定。
5、在启动和故障恢复对话框中，单击确定。
6、单击确定关闭系统属性对话框。
7、在系统设置更改对话框中，如果要立即重新启动计算机，则单击是；如果要稍后重新启动计算机，则单击否。
注：
Vista用户请类似 *** 作。 对于原版 *** 作系统，以上设置是默认的(除了禁止自动重新启动)。 对于第4点中的写入调试信息列表内容，现给出以下参照释义：
（以上三种转储文件的大小依次增大，关于三者的比较不在本文讨论范围之内，笔者仅推荐设置为“小内存转储”或者“核心内存转储”，一般性错误“小内存转储”就足够了，如不能完好分析请选择“核心内存转储”。为了数据的丰富性，您也可以直接选择“核心内存转储”，但笔者强烈不推荐完全内存转储。）
值得注意的是，为了确保崩溃时自动生成内存转储文件，您可能还须启用虚拟内存页面文件。特别地，当您选择记录核心内存转储时，您必须启用虚拟内存页面文件，而且由于核心内存转储文件的大小取决于该机器上 *** 作系统和所有活动驱动程序已经分配的内核模式内存的数量，因此没有很好的办法来预测内核内存转储的大小。下表仅给出该情况下的参考虚拟内存大小设置值：
另外，除了页面文件占用的磁盘空间，内存转储文件(DMP)的生成位置所在的磁盘还要有足够的空闲空间来提取这个转储文件，否则一样会“生成不了”(实际上是丢失了)。
设置好这些之后，一旦您的系统发生蓝屏崩溃，系统就会在以上设置中选中的相应内存转储文件类型下对应的目录处生成转储文件。您所要做的就是立刻拿出利器——启动WinDbg进行分析。
笔者在此将结合一个实例进行详细说明，过程中包含了WinDbg调试蓝屏用到的一些命令，这些命令将不再额外整理，请于阅读过程中注意识记。
首先，您要配置WinDbg将要使用的调试符号文件(Symbol File)的位置。什么是调试符号文件呢？符号文件随DLL文件或者EXE文件建立时产生，提供包含在可执行文件和动态链接库 (DLL) 中的函数的占位空间。此外，符号文件还可以表示达到失败点的函数调用路线图。当我们使用各种Microsoft工具调试应用程序时，必须拥有符号信息，这样才能正确分析出问题根源。那我们该如何设置调试符号文件的位置呢？我们既可以从微软官网下载完整的符号文件包(同位于WinDbg下载页面)，也可以使用微软的符号文件服务器(Microsoft Symbol Server)。笔者推荐后者，因为一次分析所要用到的符号文件局限于有限的几个而已，使用后者可以让程序自动下载，既节省时间，又可以确保符号文件是最新的并且是正确的。在WinDbg中点击“File”菜单，选择“Symbol File Path …”，在打开的对话框中输入
复制代码
后点击“OK”按钮即可。当然，还有一步就是再次点击“File”菜单，选择“Save Workspace”来保存当前的设置。
设置了符号文件之后，您就可以进行内存转储文件的分析了。同样点击“File”菜单，这次要选择“Open Crash Dump …”，然后通过文件打开对话框打开生成的待分析的内存转储文件。本例中设置的是核心内存转储类型，于是应该定位至“%SystemRoot%”(即系统盘Windows文件夹下)，打开MEMORYDMP文件。但是笔者已经事先将其转移至“E:\Memory Dump\MEMORYDMP”，因此在后续的中，您看到的是这个地址。此时WinDbg会滚动显示一些信息并且会稍有挂起的感觉，直到从微软符号文件服务器下载完分析这个崩溃文件所需要的所有符号文件。
在上图中，我们看到就是这个打开的调试器命令窗口(Debugger Command Window)(已经将符号文件加载完毕，待命)，我们先看看位于底部的区域6，这个小的长方条就是WinDbg的命令输入处(Command Entry)，它又分为两个区域，左边显示“0: kd>”的是提示区，右边空白区是命令输入区。当刚打开这个窗口而符号文件尚未下载/加载完毕时，提示区域会什么都不显示，而命令输入区域将显示“Debuggee not connected”。直到符号加载完毕，窗口中显示出最后一行“Followup: MachineOwner”才会变为空闲状态。在空闲状态时，它将显示为与上图中类似的模样。为什么说类似呢？因为这个空闲待命提示根据调试类型、计算机处理器硬件配置不同，比如此例中，进行的是内核调试，于是显示“kd>”(kernel debug)，系统为多(核)处理器，因此在“kd>”之前还显示一个“0:”，表明当前位于编号为0的处理器。在执行了某个命令之后，如果命令需要处理的任务较多(如“!analyze -v”)，提示区域将显示为忙碌状态的“BUSY”，一旦显示为这个状态，您不论输入什么命令都不会立即执行，而是等待变为空闲状态时延缓执行。
如上图所示，图中区域1处将显示打开的这个内存转储文件的物理路经；区域2处显示的则是当前加载的符号文件的位置，本例中表明是从微软服务器下载；区域3共有三行，显示的为系统信息，第一行表明了系统为Windows XP，内核版本为2600(SP3)，多处理器(2颗)，32位，第二行表明了系统类型为NT系统，客户端系统，第三行表明系统的详细版本标识；区域4共两行，第一行表明该内存转储文件生成的时间，也就是系统崩溃的具体时间，本例中(这是去年12月得到的一个崩溃转储文件，现用作本例进行说明)为星期六(Sat)，12月(Dec)27日，22:56:31062，2008年，格林尼治标准时间东八区(GMT+8)，第二行显示的是崩溃时自系统启动以来，系统共运行了0天4小时5分15797秒。区域5是很关键的错误信息，它的第一行仅在加载符号文件遇到错误时显示，此例中，它告诉我们“对于BaseTDISYS文件，模块已经加载完毕但却不能够为其加载符号文件”，如果之前配置了正确的符号文件路径，这就告诉我们BaseTDISYS不是微软公司的文件，而是第三方驱动程序文件，这很可能是引起错误的原因，值得关注但须进一步分析。区域5的第二行是WinDbg自动分析的结果，它告诉我们，引起崩溃的原因(Probably caused by:)很可能是HookUrlsys文件。一般情况下，这就是引起错误的罪魁祸首了，但是也有不少的例外，最典型的就是显示一个微软自己的文件在此处，您可要注意了，为了避免枉杀无辜，最好进一步分析来看看都有哪些模块牵扯在崩溃的最后一刻，这样就能够保证审判无误了！进一步分析的命令可以从“!analyze -v”开始。
我们既可以在命令输入区域手动键入命令
!analyze -v
复制代码
，也可以在上图中的区域7所示位置单击蓝色的这个命令。之后，提示区域将显示为“BUSY”，WinDbg将分析一段时间直到将结果显示完毕并再次转为空闲状态。下面我们根据一张例图阐释执行“!analyze -v”后显示的各种结果：
WinDbg经过自动的分析，可能会显示上图中区域1处所示第一行的错误检查说明(Bug Check Interpretation)，而第二行则给出了详细的解释，从图中信息看得出，此例错误由于“驱动程序在队列工作项目完成之前卸载”造成的。这个“DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS”就应该是显示在蓝屏上方的错误说明字样，后面的Arguments1~4就是蓝屏时停止代码后面的四个参数。图中区域2所示的BUGCHECK_STR是WinDbg中分了类别的错误检查(Bug Check)的一项，此例中为0xCE，也是停止代码的分类简写，我们在命令输入区执行
bugcheck
复制代码
命令，可以得到停止代码及其参数，这和上图的区域1、蓝屏上的信息是一致的。本例中可以得到如下结果：
0: kd> bugcheck
Bugcheck code 000000CE
Arguments bacb0a4e 00000008 bacb0a4e 00000000
我们在Bugcheck code值前补上“0x”就可以得到蓝屏上的信息“STOP: 0x000000CE (bacb0a4e, 00000008, bacb0a4e, 00000000)”。当然，关于这个错误如果您想了解更多，一个是可以在微软在线帮助和支持网站上搜索字符串“0x000000CE”，再就是可以利用上图中区域2的BUGCHECK_STR值“0xCE”执行
hh bug check 0xCE
复制代码
命令，在打开的窗口左栏右下角点击“Display”按钮。如果要在WinDbg中显示一个停止代码或者错误检查类的详细说明(以此错误为例)，键入命令
!analyze -show 0x000000CE
复制代码
或者
!analyze -show 000000CE
复制代码
，也可以是
!analyze -show 0xCE
复制代码
。区域3中显示的就是二审判决的重要信息——线程堆栈信息。特别注意红色框内的部分，第一行是“WARNING: Frame IP not in any known module Following frames may be wrong”意思就是“警告：堆栈帧IP(InstructionPtr，仅x86处理器，用于决定帧的堆栈回朔的指令指针)不存在于任何已知的模块中，下面的帧可能出现错误”。这个意思的解释已超出本文讨论范围，笔者仅告诉大家，这行文字下面的一行右侧的模块是系统蓝屏崩溃时刻使用的最后一个模块(除了Windows内核最后调用KeBugCheckEx牺牲自己，就是警告文字上方的三行)，往往就是它引起了崩溃！我们来细看。大家如果了解了堆栈的数据结构或是Windows内存分配机制就应该知道，Windows为 线程分配额外内存时是从高地指向低地址进行的，就是说，蓝色区域3中的堆栈信息我们得倒过来由下往上看，这样才是系统崩溃之前的一刻内核态函数的调用和传递情况，比如此例，系统内核执行体(nt!,即Ntoskrnlexe)通过函数IopfCallDriver调用了BaseTDI，然后BaseTDI又调用了HookUrlsys(Unloaded_字样表示未加载)，再然后就蓝屏了。那么在这最后一刻就涉及到了两个非Windows内核的模块——BaseTDI以及HookUrlsys。之所以要进行这个“二审判决”，就是要避免一种情况——万一HookUrlsys与BaseTDI是来自两个公司或者两个软件的模块，而最后加载的HookUrlsys是没有问题的，出错是因为BaseTDI给HookUrlsys传递了格式错误或者已被破坏的、或者非法的参数信息，HookUrlsys接受此无效数据而引发了崩溃。如果我们不看线程栈，就根据之前的“Probably Cause by：HookUrlsys”进行判决，我们很有可能枉杀无辜而让凶手逍遥法外。只有通过线程栈我们才能发现另一个驱动程序BaseTDI也被牵连进来。(在应用程序崩溃不致系统崩溃的调试分析中，由于处于用户态，WinDbg自动分析结果中的“Probably Cause by：”几乎都是错误的。在这种情况下，使用!thread命令是不能显示出任何信息的，因为这个命令仅对内核态的崩溃调试有效，然而kb命令也显示不出有用的信息，只有用“~kb”来显示详细的全部线程栈才可能发现问题根源，有的时候还需配合其他命令，本文不作讨论)
当然，如果您熟练以后，觉得没有必要使用“!analyze -v”命令的话，可以直接使用
!thread
复制代码
或者
kb
复制代码
命令显示出核心的线程栈信息来二审判决。现在好了，犯罪嫌疑人目标锁定在BaseTDI和HookUrlsys身上。现在，我们来看看它们究竟是什么、是哪个公司、哪个程序的模块。(从之前不能够自动从微软服务器为他们加载符号文件就可以知道，它们一定都是第三方驱动程序)
使用命令
lm kv m Basetdi
复制代码
(使用lm(列出模块)命令和内核k选项、详细v选项以及参数m，配合包含通配符的字符串BaseTDI，来列出当时已加载于内核模式的包含字符BaseTDI的所有驱动文件详细信息。使用通配符来取代完整的文件名后缀可以避免信息的局限性，借此也许可以发现多个相关的模块以提供更多诊断线索)，我们得到下图结果：
从图中蓝色框选部分，我们可以看出，当时内核态下只有一个叫BaseTDISYS的文件，这个文件的路径位于System32\Drivers下，属于名称为“瑞星个人防火墙”(ProductName: Rising PFW, PFW=Personal Firewall)的程序组件，软件公司注册商标为“瑞星”(LegalTrademarks: RISING)。文件的这些英文描述信息如果您不知道，可以百度一下。当然，没有被笔者高亮显示的信息(如文件时间戳、版本、校验和等等)也是非常有用的，比如百度一下文件版本，也许您会发现该软件已经提供了更新的解决此问题的文件。同样，我们使用
lm kv m hookurl
复制代码
来显示当时内核态下包含HookUrl的文件及其详细信息。结果如下：
图示是一个不令人满意的结果，因为如高亮部分所示，这个模块未被加载，因此没有信息被记录。不过我们有百度，不用急，百度一下你就知道。在搜索完HookUrlsys之后，发现这个也是瑞星个人防火墙的文件。其实这个案例就是著名的“瑞星个人防火墙跨版本升级到2009版时引发蓝屏”事件。您可以通过关键字“瑞星防火墙2009升级造成蓝屏”进行百度搜索。到目前为止，瑞星官方都没有任何针对此事件的正式答复，虽然不是每个用户都出现此问题，但是非常多的用户都报告了此问题，瑞星也不承认这个是软件缺陷，只有官方卡卡论坛上有一个不知道是不是工作人员的人发帖要求大家遇到蓝屏就上传内存转储文件。说到这里，我对瑞星又要失望了，但是通过这个可见蓝屏内存转储文件的分析是多么的有用！
在这里，我还要给出两个要得到更多信息时可能会使用到的命令，一个是
!process 0 0
复制代码
，它可以列出当时运行着的所有进程的技术信息；另一个则是
!vm
复制代码
，它能够显示出当时的虚拟内存使用情况，这对于分析系统是否耗尽了虚拟内存、换页内存池或非换页内存池，并结合进程列表找到可能的内存泄漏错误非常有用，不过已超出了本文的讨论范围。
最后，我们来看看以下的两种特殊情况该如何使用WinDbg进行调试分析：
第一种情况是系统挂起，也就是“死机”、“系统没有响应”，在这种情况下，系统是根本无法自动生成内存转储文件的，而且您也不可能 *** 作本地软件来查明是什么挂起了系统，这个时候我们需要手动让系统崩溃，以生成内存转储文件。具体做法为，在系统挂起之前，打开注册表编辑器并定位至
HKEY_LOCAL_MACHINE \System\CurrentControlSet\Services\i8042prt\Parameters
复制代码
，在该项下面建立一个名为
CrashOnCtrlScroll
复制代码
的DWORD类型键值(注意大小写)，并将其设置为1，然后重新启动应用此更改。一旦系统挂起，就可以通过按住右边Ctrl键的同时击ScrollLock键两次来生成一个停止代码为0x000000E2(MANUALLY_INITIATED_CRASH)的手动崩溃。得到内存转储文件以后按照上面的方法分析。注意，此方法对插入USB口的USB键盘无效。(笔记本计算机键盘很多都是通过PS/2接口连接的，因此有效)
第二种情况是进不了系统就自动崩溃，无法提取出内存转储文件。这种情形以及当有特定的需要时，我们都可以采取双机调试的方法。我们将发生崩溃的机器称为“目标机”，将用来连接到“目标机”进行调试的机器称为“调试主机”，调试主机必须安装有WinDbg。
首先，我们需要在两台机器间建立连接，在新版的WinDbg中，这里一共有三种方式连接到目标机。第一种方式为通过COM端口连接，使用零调制解调器线缆(Null-Modem)，也就是COM对接线——两个头都是孔的RS232线；第二种是利用IEEE 1394线缆连接，但是这种连接要求两台机器运行相同版本的至少为Windows XP的系统；第三种方式是使用特制的USB 20调试线缆连接，这不是普通的USB连接线，是一种内置硬件芯片来支持调试的线缆，而且这种方式要求目标机运行的系统至少为Windows Vista。使用这三种连接方式进行双机调试都需要在目标机上作出相应的设置调整，具体参见WinDbg帮助文件，这里仅讨论第一种连接方式的设置，因为这是XP及以上系统默认支持的最简单的方式。此时我们假设已经使用COM线缆连接好了两台机器。
其次，在调试主机上启动WinDbg，配制好符号文件之后，我们展开“File”菜单，选择“Kernal Debug…”，这将会打开如下的“Kernal Debugging”对话框：
默认打开的就是COM连接方式的配置页面。这里的“Baud Rate(传输速率)”以及“Port(端口)”需要根据下一个步骤的 *** 作方式来配置。
最后一步，我们可以启动目标机，在引导Windows之前按下F8，在启动菜单中选择“调试模式”，这样，传输速率被系统默认设为19200，端口也默认被设为COM2，因此上一步骤中应该照此设置后点击“OK”。关于XP修改Bootini、Vista修改Bootcfg的方式启用指定端口、传输速率的调试，请参见WinDbg帮助文件，在此不再赘述。目标机一起动Windows，位于调试主机的WinDbg就能够有信息的显示，然后按照本文介绍的方法进行调试。另外，对于上面提到的系统挂起的情况，也可以采用这种双机调试，并且有新的命令
crash
复制代码
强迫目标机在它的本地硬盘驱动器中生成一个崩溃转储，当系统重新引导以后就可以提取此转储，当然，也可以使用
dump /m COMdmp
复制代码
命令，在调试主机WinDbg所在目录下生成一个名叫“COMdmp”的小内存转储文件(命令中的文件名可以改成其它的)。
编辑本段
预防电脑蓝屏的九个小技巧
1 定期对重要的注册表文件进行手工备份，避免系统出错后，未能及时替换成备份文件而产生不可挽回的错误。
2 尽量避免非正常关机，减少重要文件的丢失。如．VxD ．DLL文件等。
3 对普通用户而言，只要能正常运行，没有必要去升级显卡、主板的BIOS和驱动程序，避免升级造成的危害。
4 定期检查优化系统文件，运行“系统文件检查器”进行文件丢失检查及版本校对。检查步骤参见前面相关介绍。
5 减少无用软件的安装，尽量不用手工卸载或删除程序，以减少非法替换文件和文件指向错误的出现。
6 如果不是内存特别大和其管理程序非常优秀，尽量避免大程序的同时运行，如果你发现在听MP3时有沙沙拉拉的声音，基本可以判定该故障是由内存不足而造成的。
7 定期用杀毒软件进行全盘扫描，清除病毒。
8 不上一些不熟悉的网站，对于一些网站上的带有诱惑性的和一些中奖的消息，不要点击。
9 定期升级 *** 作系统，软件和驱动。
字多了点慢慢看哈 ╮(╯▽╰)╭“苦连个”孩子

要解决此问题，请使用下列方法将处理器驱动程序恢复到正确的驱动程序。Windows XP SP2 附带正确的驱动程序 Intelppmsys。
要确定安装了哪个处理器驱动程序，请按照下列步骤 *** 作： 1 单击“开始”，单击“运行”，键入 devmgmtmsc，然后按 Enter 键。
2 在设备管理器中，展开“处理器”。
3 右键单击“Intel Pentium M 处理器”，然后单击“属性”。
4 单击“驱动程序”选项卡。
5 单击“驱动程序详细信息”。
如果 Windows XP SP2 系统正在使用 Gv3sys 处理器驱动程序，您必须更新到 Intelppmsys 处理器驱动程序才能更正此问题。为此，请按照下列步骤 *** 作。 1 单击“开始”，单击“运行”，键入 devmgmtmsc，然后按 Enter 键。
2 在设备管理器中，展开“处理器”。
3 右键单击“Intel Pentium M 处理器”，然后单击“更新驱动程序”。
驱动程序更新向导将启动。
4 如果出现“Windows 可以连接到 Windows Update 以搜索软件吗？”的提示，请单击“否，暂时不”，然后单击“下一步”。
5 单击“自动安装软件（推荐）”，然后单击“下一步”。
6 单击“完成”。
必须重新启动计算机，才能完成安装。 回答者： powertzg | 二级 | 2011-5-14 19:20
你好，是内存错误吧，重新分区后再装XP就好了
发生的原因
错误讯息中描述的档案毁损时，可能会出现这个问题。Windows 启动时，会检查下列档案的完整性：所有驱动程式档案 (但系统载入器为启动电脑而载入的驱动程式则除外)
所有动态连结程式库 (DLL)，包括使用者、图形装置介面 (GDI)、Shell、核心、Ntdll、Crtdll 等
硬体上所安装的驱动程式不适当时，可能会出现这个问题。例如，在 X86 电脑上安装 MIPS (Millions of Instructions per Second) 驱动程式时，会出现本文〈摘要〉一节中描述的其中一个错误讯息。
解决方案
如果要解决这个问题，您可以获得一份新的毁损档案，或是重新安装 Windows。如果重新安装 Windows 后仍然出现本文〈摘要〉一节中描述的错误讯息，这可能是硬体或网路的问题。

※注意※一般有这几个问题会出现这种情况：
1、内存质量不高或者接触不良或者老化。
2、硬件的驱动程序不匹配或者损坏。
3、系统遭病毒破坏某些硬件配置文件被更改。
4、有几个软件冲突。
如果是使用中出现了这种问题，并没有安装软件或驱动，要检查内存
通常是由有问题的驱动程序引起的,有缺陷的内存、 损坏的虚拟内存文件、 某些软件比如多媒体软件、杀毒软件、备份软件、DVD播放软件等也会导致这个错误
解决方案:
出现这个问题的原因很多，给你提供点线索，供参考。
1、将BIOS设置为默认值。
2、检查所有连接，给主机除尘。
3、检查散热。
4、测试内存是否存在问题，清理插槽，再插紧。
5、重新设置虚拟内存，将虚拟内存设置在空间比较大的C盘以外的分区中。
6、如果在上网时遇到这个蓝屏, 而你恰恰又在进行大量的数据下载和上传(比如:网络游戏、BT下载), 那么应该是网卡驱动的问题,更换网卡驱动或换个网卡。
7、检查最新安装或升级的驱动程序，如果蓝屏中出现"acpisys"等类似文件名, 可以非常肯定时驱动程序问题，将这个驱动卸载，重新安装适宜的驱动程序 。
8、更换显卡、声卡驱动程序
9、卸载、更换机子中的怀疑有问题的软件，特别是杀软件。更换游戏软件版本。
10、也有可能是由于硬件或其驱动程序和Windows 的电源管理不兼容。
（1）在“控制面板/电源选项”中如果有APM(高级电源管理)方面的设置，关闭APM功能。同时在“休眠”中禁用休眠功能。
（2）在BIOS中把电源管理选项“ACPI Suspend Type”设置为S1(有些机器显示为STR)或直接关闭ACPI选项。
11、重装系统。
如果还有问题请在线向我询问！ 回答者： szyangsu | 五级 | 2011-5-14 20:11
你好，电脑蓝屏，主要是：“内存有错误”或“软件不兼容”引起！
出现D1，这是：显卡的问题！驱动人生，更新：显卡驱动，试试！
这是解决方法：（作者：力王历史）
1。试试开机，出完电脑品牌后，按F8，安全模式，光标选定：最后一次正确配置，
回车，回车，按下去！关键一步
2。再不行，进安全模式，回车，到桌面后，杀毒软件，全盘杀毒！
“隔离区”的东西，彻底删除！
3。再使用：360安全卫士，“功能大全”里的：“360系统急救箱”，
点：开始急救！重启后，点开“文件恢复区”，全选，彻底删除文件！
系统修复，全选，立即修复！关键一步
网络修复，开始修复，重启电脑！
360安全卫士，扫描插件，立即清理！360安全卫士，系统修复，一键修复！
金山急救箱，勾选：扩展扫描，立即扫描，立即处理，重启电脑！
4。再不行，拔下显卡和内存条，橡皮擦擦，再用毛刷，清理插槽灰尘和风扇，
更换内存插槽等！台式机
5。检查是否有同类功能的，多余类似软件，如：多款播放器，多款杀毒软件
等，卸载多余的，只留一款，因为同类软件，互不兼容！关键一步
6。再不行，下载“驱动人生”，升级：显卡驱动！
7。如果还是不行，需要“一键还原”或“重装系统”了！
8。硬件有问题，送修！ 回答者： 力王历史 | 二十级 | 2011-5-14 21:43
0×0000000C 存取码错误。0×00000002 系统找不到指定的档案。
0x000000D1RIVER_IRQL_NOT_LESS_OR_EQUAL ◆错误分析:通常是由有问题的驱动程序引起的(比如罗技鼠标的Logitech MouseWare 910和924版驱动程序会引发这个故障) 同时,有缺陷的内存、 损坏的虚拟内存文件、 某些软件(比如多媒体软件、杀毒软件、备份软件、DVD播放软件)等也会导致这个错误 ◇解决方案:检查最新安装或升级的驱动程序(如果蓝屏中出现"acpisys"等类似文件名, 可以非常肯定是驱动程序问题)和软件; 测试内存是否存在问题; 进入"故障恢复控制台", 转到虚拟内存页面文件Pagefilesys所在分区, 执行"del pagefilesys"命令, 将页面文件删除; 然后在页面文件所在分区执行"chkdsk /r"命令;进入Windows后重新设置虚拟内存如果在上网时遇到这个蓝屏, 而你恰恰又在进行大量的数据下载和上传(比如:网络游戏、BT下载), 那么应该是网卡驱动的问题, 需要升级其驱动程序
以下情况会引发系统蓝屏崩溃： 1、运行在内核模式下的设备驱动程序或者 *** 作系统函数引发了一个未被处理的异常，比如内存访问违例（由于企图写一个只读页面或者企图读一个当前未被映射的内存地址(即无效地址)而引起）。 2、调用一个内核支持例程导致了重新调度，比如当中断请求级别(IRQL)为DPC/Dispatch级别或更高级别时等待一个标记为需要等待的调度对象。 3、在DPC/Dispatch级别或更高的IRQL级别时由于数据存在于页面文件或内存映射文件中而发生了页面错误(Page Fault)。（这将要求内存管理器必须等待一个I/O *** 作发生。但正如上面一项所说，在DPC/Dispatch级别或更高IRQL级别上不能够进行等待，因为那将要求一次重新调度）。 4、当检测到一个内部状态表明数据已遭受破坏或者在保证数据不被破坏的情况下系统无法继续执行时，设备驱动程序或 *** 作系统函数明确地要求系统崩溃（通过调用系统函数KeBugCheckEx）。 5、发生硬件错误，比如处理器的计算机检查异常功能(Machine Check)报告有异常或者发生不可屏蔽中断(NMI)。 在了解以上三点知识之后，相信您对Windows的大无畏牺牲精神会有所赞赏，也会原谅它的“蓝脸”了。其实，在绝大多数情况下均是第三方设备驱动程序导致了Windows的崩溃。对于Windows XP用户提交给微软在线崩溃分析(Microsoft OCA, Microsoft Online Crash Analysis)站点的内存转储文件，微软对引起崩溃的原因进行了统计分类，如下图所示：（数据于2004年4月份生成）。 既然Windows向我们露出了无奈的“蓝脸”，我们就应该打破沙锅问到底，尽早将引发系统崩溃的罪魁祸首缉拿归案，让我们的系统早日康复。下面，我们来看看Windows想通过这张“蓝脸”告诉我们些什么。 如上图所示，这是一张显示了所有参数的蓝屏图像。当然，我们所遇到的蓝屏图像与之可能存在差异，比如少了一些信息等，但是大致是相同的，我们就以它为例进行全面地阐述。 首先，我们看看图中用数字1标注的区域，这里列出了传递给KeBugCheckEx函数的停止代码和四个参数。此图中的停止代码为0x000000D1，四个参数为后面括号内的用逗号分隔的四段16进制数字；接下来，我们来看看图中用数字2标注的区域，这里显示的是该停止代码0x000000D1对应的英文解释；最后，我们看看图中用数字3标注的区域，这个区域当且仅当停止代码的四个参数中的一个参数包含了 *** 作系统或设备驱动程序代码的地址时才会显示，显示的内容为、该地址所处模块的基地址以及日期戳。如此例中，该设备驱动程序的文件名为“myfaultsys”。 这些信息对我们排错有何作用呢？如果上图中的区域3出现了，那是最好的结果了，因为您直接就看到了罪魁祸首——“myfaultsys”文件。但是，区域3往往是不出现的，那么我们就要在Microsoft的在线帮助和支持中查找该停止代码等信息或者使用我们的利器——WinDbg进行手动分析了。笔者推荐后者，因为同一个停止代码可能由各种各样的驱动程序错误造成，得到了停止代码并不等于得到了问题文件名称，另外，微软的在线帮助和支持中不是所有的错误都能够搜索到，而WinDbg正好克服了这两个弱点，直接能够抓出罪魁祸首文件，让您痛快将其斩首。 WinDbg是免费软件，其微软官方下载地址参考扩展阅读，具体项目为Install Debugging Tools for Windows 32/64-bit Version。 使用WinDbg分析崩溃时的内存转储文件的前提是您要让系统在崩溃时自动生成一个内存转储文件，做法如下： 1、单击开始，然后单击运行。 2、键入 control sysdmcpl 复制代码 ，然后单击确定。您将会打开系统属性，请切换到高级选项卡。结果如下图所示： 3、在高级选项卡上，在启动和故障恢复部分中单击设置。这将打开启动和故障恢复对话框，如下图所示： 4、在写入调试信息列表中，选择“小内存转储(64 KB)”或“核心内存转储”，这样系统在崩溃时将会自动生成对应的内存转储文件。如果您不想让蓝屏只闪烁一下，而是想看清楚它直到您手动重新启动计算机，请清除系统失败部分中自动重新启动(R)项目前的复选框。然后单击确定。 5、在启动和故障恢复对话框中，单击确定。 6、单击确定关闭系统属性对话框。 7、在系统设置更改对话框中，如果要立即重新启动计算机，则单击是；如果要稍后重新启动计算机，则单击否。 注： Vista用户请类似 *** 作。 对于原版 *** 作系统，以上设置是默认的(除了禁止自动重新启动)。 对于第4点中的写入调试信息列表内容，现给出以下参照释义： （以上三种转储文件的大小依次增大，关于三者的比较不在本文讨论范围之内，笔者仅推荐设置为“小内存转储”或者“核心内存转储”，一般性错误“小内存转储”就足够了，如不能完好分析请选择“核心内存转储”。为了数据的丰富性，您也可以直接选择“核心内存转储”，但笔者强烈不推荐完全内存转储。） 值得注意的是，为了确保崩溃时自动生成内存转储文件，您可能还须启用虚拟内存页面文件。特别地，当您选择记录核心内存转储时，您必须启用虚拟内存页面文件，而且由于核心内存转储文件的大小取决于该机器上 *** 作系统和所有活动驱动程序已经分配的内核模式内存的数量，因此没有很好的办法来预测内核内存转储的大小。下表仅给出该情况下的参考虚拟内存大小设置值： 另外，除了页面文件占用的磁盘空间，内存转储文件(DMP)的生成位置所在的磁盘还要有足够的空闲空间来提取这个转储文件，否则一样会“生成不了”(实际上是丢失了)。 设置好这些之后，一旦您的系统发生蓝屏崩溃，系统就会在以上设置中选中的相应内存转储文件类型下对应的目录处生成转储文件。您所要做的就是立刻拿出利器——启动WinDbg进行分析。 笔者在此将结合一个实例进行详细说明，过程中包含了WinDbg调试蓝屏用到的一些命令，这些命令将不再额外整理，请于阅读过程中注意识记。 首先，您要配置WinDbg将要使用的调试符号文件(Symbol File)的位置。什么是调试符号文件呢？符号文件随DLL文件或者EXE文件建立时产生，提供包含在可执行文件和动态链接库 (DLL) 中的函数的占位空间。此外，符号文件还可以表示达到失败点的函数调用路线图。当我们使用各种Microsoft工具调试应用程序时，必须拥有符号信息，这样才能正确分析出问题根源。那我们该如何设置调试符号文件的位置呢？我们既可以从微软官网下载完整的符号文件包(同位于WinDbg下载页面)，也可以使用微软的符号文件服务器(Microsoft Symbol Server)。笔者推荐后者，因为一次分析所要用到的符号文件局限于有限的几个而已，使用后者可以让程序自动下载，既节省时间，又可以确保符号文件是最新的并且是正确的。在WinDbg中点击“File”菜单，选择“Symbol File Path …”，在打开的对话框中输入 复制代码 后点击“OK”按钮即可。当然，还有一步就是再次点击“File”菜单，选择“Save Workspace”来保存当前的设置。 设置了符号文件之后，您就可以进行内存转储文件的分析了。同样点击“File”菜单，这次要选择“Open Crash Dump …”，然后通过文件打开对话框打开生成的待分析的内存转储文件。本例中设置的是核心内存转储类型，于是应该定位至“%SystemRoot%”(即系统盘Windows文件夹下)，打开MEMORYDMP文件。但是笔者已经事先将其转移至“E:\Memory Dump\MEMORYDMP”，因此在后续的中，您看到的是这个地址。此时WinDbg会滚动显示一些信息并且会稍有挂起的感觉，直到从微软符号文件服务器下载完分析这个崩溃文件所需要的所有符号文件。 在上图中，我们看到就是这个打开的调试器命令窗口(Debugger Command Window)(已经将符号文件加载完毕，待命)，我们先看看位于底部的区域6，这个小的长方条就是WinDbg的命令输入处(Command Entry)，它又分为两个区域，左边显示“0: kd>”的是提示区，右边空白区是命令输入区。当刚打开这个窗口而符号文件尚未下载/加载完毕时，提示区域会什么都不显示，而命令输入区域将显示“Debuggee not connected”。直到符号加载完毕，窗口中显示出最后一行“Followup: MachineOwner”才会变为空闲状态。在空闲状态时，它将显示为与上图中类似的模样。为什么说类似呢？因为这个空闲待命提示根据调试类型、计算机处理器硬件配置不同，比如此例中，进行的是内核调试，于是显示“kd>”(kernel debug)，系统为多(核)处理器，因此在“kd>”之前还显示一个“0:”，表明当前位于编号为0的处理器。在执行了某个命令之后，如果命令需要处理的任务较多(如“!analyze -v”)，提示区域将显示为忙碌状态的“BUSY”，一旦显示为这个状态，您不论输入什么命令都不会立即执行，而是等待变为空闲状态时延缓执行。 如上图所示，图中区域1处将显示打开的这个内存转储文件的物理路经；区域2处显示的则是当前加载的符号文件的位置，本例中表明是从微软服务器下载；区域3共有三行，显示的为系统信息，第一行表明了系统为Windows XP，内核版本为2600(SP3)，多处理器(2颗)，32位，第二行表明了系统类型为NT系统，客户端系统，第三行表明系统的详细版本标识；区域4共两行，第一行表明该内存转储文件生成的时间，也就是系统崩溃的具体时间，本例中(这是去年12月得到的一个崩溃转储文件，现用作本例进行说明)为星期六(Sat)，12月(Dec)27日，22:56:31062，2008年，格林尼治标准时间东八区(GMT+8)，第二行显示的是崩溃时自系统启动以来，系统共运行了0天4小时5分15797秒。区域5是很关键的错误信息，它的第一行仅在加载符号文件遇到错误时显示，此例中，它告诉我们“对于BaseTDISYS文件，模块已经加载完毕但却不能够为其加载符号文件”，如果之前配置了正确的符号文件路径，这就告诉我们BaseTDISYS不是微软公司的文件，而是第三方驱动程序文件，这很可能是引起错误的原因，值得关注但须进一步分析。区域5的第二行是WinDbg自动分析的结果，它告诉我们，引起崩溃的原因(Probably caused by:)很可能是HookUrlsys文件。一般情况下，这就是引起错误的罪魁祸首了，但是也有不少的例外，最典型的就是显示一个微软自己的文件在此处，您可要注意了，为了避免枉杀无辜，最好进一步分析来看看都有哪些模块牵扯在崩溃的最后一刻，这样就能够保证审判无误了！进一步分析的命令可以从“!analyze -v”开始。 我们既可以在命令输入区域手动键入命令 !analyze -v 复制代码 ，也可以在上图中的区域7所示位置单击蓝色的这个命令。之后，提示区域将显示为“BUSY”，WinDbg将分析一段时间直到将结果显示完毕并再次转为空闲状态。下面我们根据一张例图阐释执行“!analyze -v”后显示的各种结果： WinDbg经过自动的分析，可能会显示上图中区域1处所示第一行的错误检查说明(Bug Check Interpretation)，而第二行则给出了详细的解释，从图中信息看得出，此例错误由于“驱动程序在队列工作项目完成之前卸载”造成的。这个“DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS”就应该是显示在蓝屏上方的错误说明字样，后面的Arguments1~4就是蓝屏时停止代码后面的四个参数。图中区域2所示的BUGCHECK_STR是WinDbg中分了类别的错误检查(Bug Check)的一项，此例中为0xCE，也是停止代码的分类简写，我们在命令输入区执行 bugcheck 复制代码 命令，可以得到停止代码及其参数，这和上图的区域1、蓝屏上的信息是一致的。本例中可以得到如下结果： 0: kd> bugcheck Bugcheck code 000000CE Arguments bacb0a4e 00000008 bacb0a4e 00000000 我们在Bugcheck code值前补上“0x”就可以得到蓝屏上的信息“STOP: 0x000000CE (bacb0a4e, 00000008, bacb0a4e, 00000000)”。当然，关于这个错误如果您想了解更多，一个是可以在微软在线帮助和支持网站上搜索字符串“0x000000CE”，再就是可以利用上图中区域2的BUGCHECK_STR值“0xCE”执行 hh bug check 0xCE 复制代码 命令，在打开的窗口左栏右下角点击“Display”按钮。如果要在WinDbg中显示一个停止代码或者错误检查类的详细说明(以此错误为例)，键入命令 !analyze -show 0x000000CE 复制代码 或者 !analyze -show 000000CE 复制代码 ，也可以是 !analyze -show 0xCE 复制代码 。区域3中显示的就是二审判决的重要信息——线程堆栈信息。特别注意红色框内的部分，第一行是“WARNING: Frame IP not in any known module Following frames may be wrong”意思就是“警告：堆栈帧IP(InstructionPtr，仅x86处理器，用于决定帧的堆栈回朔的指令指针)不存在于任何已知的模块中，下面的帧可能出现错误”。这个意思的解释已超出本文讨论范围，笔者仅告诉大家，这行文字下面的一行右侧的模块是系统蓝屏崩溃时刻使用的最后一个模块(除了Windows内核最后调用KeBugCheckEx牺牲自己，就是警告文字上方的三行)，往往就是它引起了崩溃！我们来细看。大家如果了解了堆栈的数据结构或是Windows内存分配机制就应该知道，Windows为 线程分配额外内存时是从高地指向低地址进行的，就是说，蓝色区域3中的堆栈信息我们得倒过来由下往上看，这样才是系统崩溃之前的一刻内核态函数的调用和传递情况，比如此例，系统内核执行体(nt!,即Ntoskrnlexe)通过函数IopfCallDriver调用了BaseTDI，然后BaseTDI又调用了HookUrlsys(Unloaded_字样表示未加载)，再然后就蓝屏了。那么在这最后一刻就涉及到了两个非Windows内核的模块——BaseTDI以及HookUrlsys。之所以要进行这个“二审判决”，就是要避免一种情况——万一HookUrlsys与BaseTDI是来自两个公司或者两个软件的模块，而最后加载的HookUrlsys是没有问题的，出错是因为BaseTDI给HookUrlsys传递了格式错误或者已被破坏的、或者非法的参数信息，HookUrlsys接受此无效数据而引发了崩溃。如果我们不看线程栈，就根据之前的“Probably Cause by：HookUrlsys”进行判决，我们很有可能枉杀无辜而让凶手逍遥法外。只有通过线程栈我们才能发现另一个驱动程序BaseTDI也被牵连进来。(在应用程序崩溃不致系统崩溃的调试分析中，由于处于用户态，WinDbg自动分析结果中的“Probably Cause by：”几乎都是错误的。在这种情况下，使用!thread命令是不能显示出任何信息的，因为这个命令仅对内核态的崩溃调试有效，然而kb命令也显示不出有用的信息，只有用“~kb”来显示详细的全部线程栈才可能发现问题根源，有的时候还需配合其他命令，本文不作讨论) 当然，如果您熟练以后，觉得没有必要使用“!analyze -v”命令的话，可以直接使用 !thread 复制代码 或者 kb 复制代码 命令显示出核心的线程栈信息来二审判决。现在好了，犯罪嫌疑人目标锁定在BaseTDI和HookUrlsys身上。现在，我们来看看它们究竟是什么、是哪个公司、哪个程序的模块。(从之前不能够自动从微软服务器为他们加载符号文件就可以知道，它们一定都是第三方驱动程序) 使用命令 lm kv m Basetdi 复制代码 (使用lm(列出模块)命令和内核k选项、详细v选项以及参数m，配合包含通配符的字符串BaseTDI，来列出当时已加载于内核模式的包含字符BaseTDI的所有驱动文件详细信息。使用通配符来取代完整的文件名后缀可以避免信息的局限性，借此也许可以发现多个相关的模块以提供更多诊断线索)，我们得到下图结果： 从图中蓝色框选部分，我们可以看出，当时内核态下只有一个叫BaseTDISYS的文件，这个文件的路径位于System32\Drivers下，属于名称为“瑞星个人防火墙”(ProductName: Rising PFW, PFW=Personal Firewall)的程序组件，软件公司注册商标为“瑞星”(LegalTrademarks: RISING)。文件的这些英文描述信息如果您不知道，可以百度一下。当然，没有被笔者高亮显示的信息(如文件时间戳、版本、校验和等等)也是非常有用的，比如百度一下文件版本，也许您会发现该软件已经提供了更新的解决此问题的文件。同样，我们使用 lm kv m hookurl 复制代码 来显示当时内核态下包含HookUrl的文件及其详细信息。结果如下： 图示是一个不令人满意的结果，因为如高亮部分所示，这个模块未被加载，因此没有信息被记录。不过我们有百度，不用急，百度一下你就知道。在搜索完HookUrlsys之后，发现这个也是瑞星个人防火墙的文件。其实这个案例就是著名的“瑞星个人防火墙跨版本升级到2009版时引发蓝屏”事件。您可以通过关键字“瑞星防火墙2009升级造成蓝屏”进行百度搜索。到目前为止，瑞星官方都没有任何针对此事件的正式答复，虽然不是每个用户都出现此问题，但是非常多的用户都报告了此问题，瑞

---