由于设备驱动存在错误、或者硬件存在问题，抑或是操作系统本身的原因，当系统遇到无法恢复的内核模式错误时，Windows会显示臭名卓著的“蓝屏死机”，随后强行中止系统，以防止磁盘出现数据冲突，同时根据系统配置的情况，还会把部分或者全部的物理内存写入到一个故障转储文件（crash dumpfile）。内存转储文件很有用，因为当我们死机后重启系统时，微软的在线故障分析服务（OCA）可以对其进行分析，以便找到问题的根源。如果我们愿意，还可以自己用Microsoft Debugging Tools for Windows自己进行故障分析。
盆盆评注：有关如何用Debug工具分析系统故障的知识，可以参考张银魁老师的Webcast。
然而旧版本的Windows，直到会话管理器进程（%Systemroot%\System32\Smss.exe）对页面文件进行初始化以后，才可以启用故障转储文件的支持。也就是说，在这以前，如果发生了严重的系统故障而导致系统蓝屏，并不会生成转储文件。而大量设备驱动程序是在Smss.exe进程启动之前进行初始化，所以早期的系统故障并不会触发转储文件的创建，所以对这些故障进行排错就非常困难。
盆盆评注：有关Windows 2000/XP启动过程的介绍，可以参考张银魁老师的Webcast。
而WindowsVista则大大提前了可以创建转储文件的时间。现在，在所有启动类型为“boot”的驱动程序启动以后，而在所有启动类型为“system”的驱动程序启动以前，就可以初始化转储文件的支持。有了这个改进，当我们在系统引导阶段遇到死机崩溃的故障，微软OCA服务就可以帮助诊断这个问题。而且，WindowsVista以64KB的块级别往转储文件里填充数据，而老版本的Windows则是以4KB为单位。这样大容量的内存转储文件，就能够以十倍的速度生成。
盆盆评注：启动类型为“boot”，是指由ntldr或者引导管理器加载的驱动程序。这些驱动程序比较重要，如果没有启动的话，Windows将无法继续引导。启动类型为“system”，是指内核初始化过程中启动的驱动程序。
在WindowsVista中，应用程序的故障处理也得到了很好的改进。在旧版本的Windows中，当应用程序发生故障时，会执行一个专门的处理程序（unhandled exceptionhandler），以对这种无法正常处理的例外进行处理。例外处理程序会加载微软的应用程序错误报告（AER）进程（%Systemroot%System32\Dwwin.exe），并且显示对话框，提示该程序出错，并询问是否需要把错误报告发送给微软。然而，如果该进程在崩溃时，主线程的堆栈被破坏，例外处理程序会在执行时崩溃，导致其进程被内核终止，结果是程序窗口一闪而过，根本没有显示任何错误报告对话框。
Windows Vista则将错误处理从崩溃进程的上下文中移走，而交由一个新的服务来处理，就是Windows Error Reporting（WER）服务。该服务运行在服务宿主进程中，是以DLL文件的形式实现的（%Systemroot%\System32\Wersvc.dll）。当应用程序发生故障时，它还是会执行例外处理程序，但是例外处理程序会给WER服务发送一个消息，而由WER服务加载WER错误报告进程（%Systemroot%\System32Werfault.exe），以显示错误报告对话框。如果因为主线程的堆栈被破坏而导致例外处理程序崩溃，例外处理程序就会反复地执行崩溃、崩溃执行，最终把线程所有堆栈空间消耗干净，当内核处于这个状态的时候，就会给WER服务发送故障通知消息。
盆盆评注：服务宿主进程，就是指svchost进程。
我们可以在以下四张图片中看到两种实现方法的对比。这些图片显示Accvio.exe进程和错误报告进程之间的关系，Accvio.exe进程是一个故障测试程序，可以触发一个应用程序崩溃。WindowsVista中新的错误处理机制意味着应用程序不再会悄无声息地中止，而妨碍我们向微软发送错误报告，以便帮助软件开发商改进他们的产品。
Windows XP的应用程序错误处理
Windows XP的错误报告对话框
Windows Vista的应用程序错误处理
Windows Vista的错误报告对话框
盆盆评注：从图1中可以看出，WindowsXP的错误报告进程dwwin是由发生错误的应用程序所启动，如果该应用程序的主线程堆栈被破坏，会导致无法弹出错误报告。而图3显示WindowsVista的错误报告进程WerFault是由svchost进程启动的（实际上是由svchost进程里的WER服务所加载），这样的相对独立机制，可以确保应用程序的错误都能被系统所捕获。
联系客服
