蓝屏了怎么办？写在开启Windbg之旅前的话

love

BIOS工程师除了处理千奇百怪的硬件错误之外，最常碰到的头痛问题就是蓝屏了。蓝屏有一万种可能：错误的ACPI表，中断没有配置正确，驱动错误等等。对付蓝屏最常用的武器就是Windbg了，连好了Windbg，蓝屏的时候会自动停下来，等待你去解决。Windbg十分的好用，起码比它的Linux兄弟要好用的多。有了它，很多问题就可以迎刃而解，熟练的掌握了它，不但可以调试硬件/BIOS错误，还可以调试驱动，甚至应用程序。也有很多同学留言希望介绍Windbg的调试技巧，我也不是Windbg的专家，只是在日常工作中有一些经验，分享出来给大家。

在开始祭出Windbg这个大杀器之前，我们其实还有一些别的选择。本文就介绍几个小工具，也许你并不需要Windbg就可以解决部分蓝屏的问题。

BlueScreenView

蓝屏之后，系统缺省会存储系统转储文件。转储文件有三种：完整转储、内核转储和mini转储。三者包含内容依次减少，大小也依次减小。缺省的是minidump，它被放在windows目录下的Minidump文件夹下（例如C:\Windows\Minidump）,会被加入日期和序号等依次存储。后面两种放在windows的根目录，默认为memory.dmp，新的会替代旧的。本文重点介绍minidump文件。

minidump文件有蓝屏当时系统内核的很多关键信息，很多时候熟悉Windbg人会需要你提供该文件，以方便分析。如果你的系统没有存储minidump文件，在这里打开：

• 在“计算机”上点击右键选择“属性”；
• 在系统信息表中选择“高级系统设置”：
  

• 选择“设置”：
  

• 设置存储文件：
  

这些设置好以后，以后每次蓝屏，都会有minidump文件存储下来。

有了minidump文件之后，我们可以用一个离线小工具来简单分析这个文件：BlueScrennView。它是一个绿色免费工具：

Blue screen of death (STOP error) information in dump files.​
www.nirsoft.net/utils/blue_screen_view.html#DownloadLinks

打开它是这样：

窗口上半部分是在缺省位置找到的所有的minidump文件，下半部分是模拟的蓝屏信息。我们可以看到是RwDrv.sys

驱动造成的stop code为0x3b（SYSTEM_SERVICE_EXCEPTION）的蓝屏。注意这里的窗口内容都可以剪贴的复制。

我们可以选择“All Drivers”形式，可以看到更多内容：

它会列出蓝屏当时所有的驱动，并将当时造成蓝屏原因的调用栈（call stack）上的驱动高亮，也就是我用红框标出的部分。我们可以右键点击或者双击看看该驱动的具体位置等等信息。

值得一提的是该软件还有快捷键帮你你一键Google蓝屏错误码，不过国内不好使。

那么这个蓝屏是什么原因呢？RwDrv.sys能不能让你想起什么呢？

也许是最良心的硬件信息读取工具：RW-everything

时为了演示拍图，结果不小心输错了地址，RwEverything的内核驱动RwDrv.sys也没有检查，就直接操作，结果蓝屏了。写篇文章真不容易啊，惨。

我们也可以用它来分析别人给的文件，在这里打开别的文件：

打开后：

这个是什么原因?哈哈，是我为了debug一个驱动，手动生成的蓝屏，所以是MANUALLY_INITIATED_CRASH，就是为了生成minidump文件。

最后要说明的是这个程序支持几乎所有版本的Windows，从WinXP到Win10，IA32和X64。并有中文包。

WinCrashReport

一般的应用程序遇到异常会被异常处理程序捕捉，如果程序的异常处理没有做好，系统的异常处理程序会弹出熟悉的画面：

WinXP

Win7/Vista

我们除了知道谁死机了外几乎没有得到什么有用的信息。我们可以选择使用WinCrashReport:

它会告诉我们丰富的多的内容：

其中有几个比较有意义：

• Strings in the stack: 会将栈上的字符串显示出来，很多时候会给你一些提示。
• Call Stack
• Modules List
• All Threads
• Full Stack Data
  

有了这些数据，又是并不需要跟踪，也能猜出个大概。

Windows蓝屏相比Linux kernel panic相对好解决，一个重要原因是它有一个强大的debug工具：WinDbg。WinDbg十分的好用，起码比Linux GDB/KDB要好用的多。有了它，很多问题就可以迎刃而解，熟练的掌握了它，不但可以调试硬件/BIOS错误，还可以调试驱动，甚至应用程序。它可以独立使用，也可以仅仅作为前端，后端连接Intel ITP、GDB甚至是UEFI BIOS的debug agent，可谓是“居家旅行，杀人灭口的必备良药“。

尽管WinDbg可以调试本机的驱动和应用程序，但调试本机的Windows内核则非其力所能及。一般来讲，WinDbg调试内核需要两台机器：Host和Target
WinDbg调试环境

我的Host是我日常用的NUC豆子峡谷：

Target是Intel最新的Alderlake （ADL）开发板：

从图中可以看到两者都插有一个USB连线，这个线是专用USB 3.0 debug线。USB 3.0 debug cable是一种内部做了遮蔽的A口公对公线，可以在淘宝上买到，我用的是这种[1]。

其中附送一个转USB Type C的头，可以连接Type C口调试，十分方便。

Target机准备

目标机需要打开调试，输入msconfig打开系统配置工具。在引导>高级选项下面：

勾选调试，调试端口选择USB，USB目标名称随便写一个自己能记住的名字。将来Host和Target两端要靠这个名字进行匹配。关闭系统配置工具，系统提示要重新启动：

我们还要确定一件事，先不选择启动。

BIOS和硬件工程师经常用到的软件：RW-Everything（以下简称RW）：

今天我要介绍一个在某种程度更好的工具：Hardware RW

（以下简称HE）：

http://hwrw.phpnet.us/

和RW一样，HE也是完全免费使用的。与RW相比，HE增加了很多功能、提供了更多的硬件信息解析和操作系统信息，可以认为它是RW+CPU-Z（mini版）+AIDA（mini版啦）的集成体。

HE的功能

在HE主页上可以下载安装包或者Portable版本，懒惰的我当然用Portable版本了：

或者USBView工具。观看系统有几个xhci控制器，在我的系统里面只有一个：

这个是PCH内置的USB 3.2控制器。如果你是通过外插PCIe USB的方式调试，你可能会看到两个以上的xhci控制器。如果仅仅一个xhci（大多数情况），就什么都不用做了。如果是两个以上，你需要在HE里面找到它的PCI BDF号码（Bus、Device、Func），再用bcdedit配置USB控制器信息，具体可以参考[2]。

好了，Target机准备完毕，我们可以看看Host端需要准备什么。

Host端软件准备

Host端需要安装WinDbg。目前有两种WinDbg，在Microsoft应用商店里面可以下载免费的WinDbg Preview，只要在应用商店里面搜索WinDbg，就可以下载安装，十分方便。

WinDbg Preview界面比较现代，但其中缺乏一些重要的内容。我推荐同时安装传统的Windbg工具，搜索Window 10 SDK，或者直接点击参考资料3[3]。Win10 SDK很大，不需要都装，只要安装“Debugging Tools for Windows”即可。

两个安装完毕后，还要做一些必要的准备工作。

首先要设置Symbols，也就是调试符号文件的路径。微软为了方便开发，会定期发布调试符号文件包，也有Symbols服务器，建议使用调试符号服务器。在传统的WinDbg里面打开

在WinDbg Preview里面在Setting的Debugging Settings里：

我的Symbols path是：“c:\MySymbols;srv*c:\MySymbols*https://msdl.microsoft.com/download/symbols”

它是什么意思呢？就是Symbols要不在我的C盘MySymbols目录下;要不去微软Symbol服务器下载下来，存在C盘MySymbols下。这个c:\MySymbols不需要我们手动创建，下载的时候没有会自动创建。自动下载比较好，随着Win10不停地推送patch，内核的各个模块升级对应不同的symbol文件，他们会在模块名称下面不同的hash值目录下各自展开，互不干扰。这个内核模块，是目标机器的内核模块而不是Host的内核模块。这样你今天可以调试21H1的模块，明天可以调试20H3的模块，完全没有问题。唯一的问题是，调试的多了后，太多pdb文件可能需要定时清理

设置好了Symbol路径后，我们可以开始准备调试了。在WinDbg Preview中：

选择Attach to kernel，在调试目标中选择USB，注意Target 名字要和Target机器设置的完全一样。

好了。万事俱备了，开动！按下回车，WinDbg显示：

忽略这个error。Target机器选择重启，静待奇迹发生！可惜什么都没有发生，Target直接蓝屏重启了，哪里出错了呢？

USB debug cable驱动安装问题

这实际上是USB 3.0调试线的驱动没有装好的问题。打开设备管理器，发现一个大大的惊叹号：

那么驱动在哪里呢？这就是我为什么建议要安装传统WinDbg的原因，在Win10 SDK安装包里面有USB驱动，会随着“Debugging Tools for Windows”一起安装。右键点击这个设备选择更新驱动程序，在WinDbg目录下有个USB目录：

驱动就在这里。注意上面说的USBView也在根目录。

安装好USB驱动后，设备正常了：

注意如果你去网上搜索某些驱动安装包，因为驱动程序的兼容性问题，很可能出现发现设备但运行不正常的情况。这里强烈建议安装最新的Win10 SDK，驱动也可以选择最新的目录下驱动。

开始调试

好了，再来一次。这次终于正常了：

由于我们选择的break at connection，所以在Windows 10的小点转圈的地方就停下来了。我们可以按下F10建，单步走几步：

我们来看看Win10跑到哪里了，选择Modules：

这时候Windows 10刚刚起来第一个模块ntkrnlmp.exe，这个就是OS的Kernel MP版本，ACPI等等统统没有准备好。如果我们键入!acpiinf，会发现ACPI表没有准备好呢。

还是让子弹再飞一会，输入g，继续跑。进到操作系统里面，再次键入!acpiinf

键入!acpitable

好了，一切正常，我们下次继续！

后记

WinDbg命令很多，我们后面计划分成两个部分讲解：

1.ACPI ASL debug

2.蓝屏case study

再开始之前，建议大家购买前Intel员工——张工的《软件调试》，里面保罗万象，内容十分丰富。