Windbg蓝屏故障排除
最近蓝屏的朋友不少，其解决方法无过于提供蓝屏代码、截屏或提供dump文件。其实蓝屏的关键问题在于找到引发蓝屏故障的文件，找到文件后按图索骥来排除故障。这里不推荐提供蓝屏代码的方法，因为不同原因会引起相同代码的蓝屏而且坦言之俺经常见到的代码一般不在所谓的代码大全里，搜索引擎一搜一大片但故障源五花八门，令人眼花缭乱。今天俺推荐大家使用微软出品的Windbg结合dump来进行蓝屏故障的排除。
首先回答一些基本问题
1、Windbg是什么？
这是官方的解释，说白了就是个调试工具，下载地址见该处http://www.microsoft.com/whdc/devtools/debugging/default.mspx
2、安装时注意问题
安装要找好对应版本，同时为了方便我们分析故障，我们需要特征库支持，理论上特征库越全越有分析出来的可能，但特征库体积很庞大，所以建议找好自己对应版本最重要。详见http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx#d 微软很迅速，win7的特征库都搞上去了。
3、dump文件是什么？
这里指内存转储文件，生成dump文件这一功能需要开启，当蓝屏时会生成该文件。而今天讲的主题就是围绕该文件展开的。
4、如何生成该文件？
在 Windows中进入控制面板、打开“系统”属性、切换到“高级”选项卡、然后打开“启动和故障恢复”选项，在“写入调试信息”下面选择“小内存转储（64KB）”、“核心内存转储”或“核心内存转储”，以便在发生蓝屏死机时自动保存内存转储文件，这样我们就可以根据 Windows在蓝屏死机时记录的内存转储文件判断故障原因了。
下面讲应用实例
1、打开windbg程序，加载样本库
2、加载蓝屏后生成的dmp文件，其中，“小内存转储”文件保存在 Windows\Minidump 文件夹中，文件大小为64KB，它只记录有发生蓝屏死机时的关键信息；“核心内存转储”及“完全内存转储”文件则保存在 Windows 文件夹中，文件名为MEMORY.DMP，它们分别记录有发生蓝屏死机时的核心内存信息和完整的内存信息。
3、加载后会自动分析该文件，我们只关心bugcheck analysis后的内容，前面主要是调试信息
该次蓝屏是由俺使用冰刃结束系统关键进程导致的，由此可见windbg的分析能力很务实，同时也告诫大家有些辅助工具很强大
下面讲一下可能出现的问题
1、特征库无法分析完整
如果你的硬盘够大，多加几个样本库有利于分析
2、分析出的问题文件为系统文件
可能会是升级导致的，也有可能感染蠕虫，此时要谨慎处理不要直接删除或卸载。
3、分析出的问题文件为应用软件文件
一般不会仅提示一个文件，有时会提及多个文件，这时考虑软件间兼容性
4、问题文件为硬件相关驱动
这种状况多发于更新驱动后，建议使用认证过的驱动
5、它与事件查看器的记录区别
如图，事件查看器可以帮助你找到代码，但不代表帮你找到出问题的文件
最后，可能细心的朋友看到了windbg介绍中最后的一句。没错，结合微软另一个工具wdk我们可以打造一张故障排除盘，而这张盘可以直接对关键系统文件如注册表进行访问修改而不是像pe那样以另一个系统的身份访问。当然将该工具集成到pe里也不错，只是特征库文件的体积有点过于庞大。
本文旨在给大家提供故障排除思路，鉴于俺目前也处于对该软件的学习期，文中不当之处还请多多包涵。另外，该软件也可以识别一些BUG，但俺还没搞懂识别方法，相信自主探索的过程会增长很多知识的。
首先回答一些基本问题
1、Windbg是什么？
You can use Debugging Tools for Windows to debug drivers, applications, and services on systems that are running Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, or Windows Server 2008. You can also use Debugging Tools for Windows to debug the operating system itself. Versions of the Debugging Tools for Windows package are available for 32-bit x86, native Intel Itanium, and native x64 platforms.
The latest release of Debugging Tools for Windows is available for download (see the Using Debugging Tools for Windows section on this page). You can also install the package from the Windows Driver Kit (WDK), the Platform SDK, or a Customer Support Diagnostics CD.
这是官方的解释，说白了就是个调试工具，下载地址见该处http://www.microsoft.com/whdc/devtools/debugging/default.mspx
2、安装时注意问题
安装要找好对应版本，同时为了方便我们分析故障，我们需要特征库支持，理论上特征库越全越有分析出来的可能，但特征库体积很庞大，所以建议找好自己对应版本最重要。详见http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx#d 微软很迅速，win7的特征库都搞上去了。
3、dump文件是什么？
这里指内存转储文件，生成dump文件这一功能需要开启，当蓝屏时会生成该文件。而今天讲的主题就是围绕该文件展开的。
4、如何生成该文件？
在 Windows中进入控制面板、打开“系统”属性、切换到“高级”选项卡、然后打开“启动和故障恢复”选项，在“写入调试信息”下面选择“小内存转储（64KB）”、“核心内存转储”或“核心内存转储”，以便在发生蓝屏死机时自动保存内存转储文件，这样我们就可以根据 Windows在蓝屏死机时记录的内存转储文件判断故障原因了。
下面讲应用实例
1、打开windbg程序，加载样本库
2、加载蓝屏后生成的dmp文件，其中，“小内存转储”文件保存在 Windows\Minidump 文件夹中，文件大小为64KB，它只记录有发生蓝屏死机时的关键信息；“核心内存转储”及“完全内存转储”文件则保存在 Windows 文件夹中，文件名为MEMORY.DMP，它们分别记录有发生蓝屏死机时的核心内存信息和完整的内存信息。
3、加载后会自动分析该文件，我们只关心bugcheck analysis后的内容，前面主要是调试信息
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [F:\WINDOWS\Minidump\Mini031509-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: F:\WINDOWS\Symbols
Executable search path is:
Unable to load image ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Machine Name:
Kernel base = 0x804d8000 PsLoadedModuleList = 0x8055e720
Debug session time: Sun Mar 15 15:49:36.812 2009 (GMT+8)
System Uptime: 0 days 2:38:49.569
Unable to load image ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Loading Kernel Symbols
...............................................................
................................................................
..............
Loading User Symbols
Loading unloaded module list
......................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 1000008E, {c0000005, 805f1ccc, b311d7ec, 0}
Unable to load image IsDrv122.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for IsDrv122.sys
*** ERROR: Module load completed but symbols could not be loaded for IsDrv122.sys
Probably caused by : IsDrv122.sys ( IsDrv122+14b30 )
Followup: MachineOwner
---------
1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 805f1ccc, The address that the exception occurred at
Arg3: b311d7ec, Trap Frame
Arg4: 00000000
Debugging Details:
------------------
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - "0x%08lx"
FAULTING_IP:
nt!MmCallDllInitialize+12b
805f1ccc a5 movs dword ptr es:[edi],dword ptr [esi]
TRAP_FRAME: b311d7ec -- (.trap 0xffffffffb311d7ec)
ErrCode = 00000000
eax=b311d8b0 ebx=b311d8b0 ecx=00a9762d edx=00000000 esi=00000068 edi=b311d928
eip=805f1ccc esp=b311d860 ebp=b311d86c iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
nt!MmCallDllInitialize+0x12b:
805f1ccc a5 movs dword ptr es:[edi],dword ptr [esi] es:0023:b311d928=00000000 ds:0023:00000068=????????
Resetting default scope
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x8E
PROCESS_NAME: IceSword.exe
LAST_CONTROL_TRANSFER: from 805f1dec to 805f1ccc
STACK_TEXT:
b311d86c 805f1dec 84b7c020 84c06270 b311d8b0 nt!MmCallDllInitialize+0x12b
b311d88c 805bccc6 b311d8b0 b311d924 001f0fff nt!MiLoadImageSection+0x2e2
b311d944 b3023b30 8055d0c0 00000000 00000000 nt!NtSetSystemInformation+0x31f
WARNING: Stack unwind information not available. Following frames may be wrong.
b311d9a4 b3011e57 89b1fb50 00000001 00000000 IsDrv122+0x14b30
b311dbc0 b3011840 84ba03e8 89b1fb50 00000004 IsDrv122+0x2e57
b311dc40 804f019f 84aacf18 84ba03e8 806e7410 IsDrv122+0x2840
b311dc64 805817f7 84aacf18 84ba03e8 84bbbe60 nt!MiFlushSectionInternal+0x256
b311dd00 8057a274 00000068 00000000 00000000 nt!NtSetInformationThread+0x125
b311dd34 8054262c 00000068 00000000 00000000 nt!SepOpenTokenOfThread+0x87
b311dd64 0041149b badb0d00 0013fa9c b3171d98 nt!RtlIpv4StringToAddressExW+0xad
b311dd78 00000000 00000000 00000000 00000000 0x41149b
STACK_COMMAND: kb
FOLLOWUP_IP:
IsDrv122+14b30
b3023b30 ?? ???
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: IsDrv122+14b30
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: IsDrv122
IMAGE_NAME: IsDrv122.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 46d28e35
FAILURE_BUCKET_ID: 0x8E_IsDrv122+14b30
BUCKET_ID: 0x8E_IsDrv122+14b30
Followup: MachineOwner
该次蓝屏是由俺使用冰刃结束系统关键进程导致的，由此可见windbg的分析能力很务实，同时也告诫大家有些辅助工具很强大
下面讲一下可能出现的问题
1、特征库无法分析完整
如果你的硬盘够大，多加几个样本库有利于分析
2、分析出的问题文件为系统文件
可能会是升级导致的，也有可能感染蠕虫，此时要谨慎处理不要直接删除或卸载。
3、分析出的问题文件为应用软件文件
一般不会仅提示一个文件，有时会提及多个文件，这时考虑软件间兼容性
4、问题文件为硬件相关驱动
这种状况多发于更新驱动后，建议使用认证过的驱动
5、它与事件查看器的记录区别
如图，事件查看器可以帮助你找到代码，但不代表帮你找到出问题的文件
最后，可能细心的朋友看到了windbg介绍中最后的一句。没错，结合微软另一个工具wdk我们可以打造一张故障排除盘，而这张盘可以直接对关键系统文件如注册表进行访问修改而不是像pe那样以另一个系统的身份访问。当然将该工具集成到pe里也不错，只是特征库文件的体积有点过于庞大。
本文旨在给大家提供故障排除思路，鉴于俺目前也处于对该软件的学习期，文中不当之处还请多多包涵。另外，该软件也可以识别一些BUG，但俺还没搞懂识别方法，相信自主探索的过程会增长很多知识的。