电脑蓝屏，又叫蓝屏死机（Blue Screen of Death，简称BSOD），是微软的Windows 系列操作系统在无法从一个系统错误中恢复过来时，为保护电脑数据文件不被破坏而强制显示的屏幕图像。 Windows操作系统的蓝屏死机提示已经成为标志性的画面。 大部分是系统崩溃的现象。
蓝屏被windows系统当作一种严重错误的保护机制，在预览版本中显示为绿色，部分windows11版本显示为黑色！
该教程适用于大部分windows版本，windbg的旧版本可以在以前的windows中使用windbg用于调试windows程序和解析转储文件。
本站收集的一些蓝屏工具！
链接：https://share.weiyun.com/xST8hyKm 密码：3bjh97
常用的是BlueScreenView和WinDbg，BlueScreenView简单，打开后，有几个文件就是系统蓝屏几次，但不能看出具体是哪一个程序引起的蓝屏！
BlueScreenView
BluescreenView是一款无需安装、独立运行的Windows蓝屏分析诊断工具。 它能够自动扫描并分析系统中的小存储器转储文件（Minidump），帮助用户快速识别导致系统崩溃的驱动、模块或软件问题。
本软件是一款非常小巧的系统蓝屏日志分析工具，很多时候Windows自己蓝屏了找不到蓝屏代码，用本工具也能分析出问题出现在哪儿。
打开能自动读取系统日志，可以看到问题出在哪个文件上，然后搜索相关文件寻求解决方案。
BlueScreenView扫描您在“蓝屏”崩溃期间创建的所有小型转储文件，并将有关所有崩溃的信息显示在一个表中。对于每次崩溃，BlueScreenView都会显示小型转储文件名，崩溃的日期/时间，蓝屏中显示的基本崩溃信息（错误检查代码和4个参数）以及可能导致崩溃的驱动程序或模块的详细信息（文件名，产品名称，文件描述和文件版本）。
对于上部窗格中显示的每个崩溃，您可以在下部窗格中查看崩溃期间加载的设备驱动程序的详细信息。BlueScreenView还标记了驱动程序其地址已在崩溃堆栈中找到，因此您可以轻松地找到可能导致崩溃的可疑驱动程序。
使用说明
这里只有一个042521-11390-01.dmp，说明只蓝屏过一次。下面的两个红底色的文件是引起这次蓝屏的文件，但很多时候，都是第三方程序引起系统程序崩溃，而这里只能看到最终的系统程序，所以无法准备定位到具体那一个程序引起的蓝屏。
命令行选项
/ LoadFrom <来源> 指定要加载的源。
1->从单个MiniDump文件夹加载（/ MiniDumpFolder参数）
2->从计算机列表文件中指定的所有计算机加载。（/ ComputersFile参数）
3->从单个MiniDump文件加载（/ SingleDumpFile参数）
/ MiniDumpFolder <文件夹> 使用指定的MiniDump文件夹启动BlueScreenView。
/ SingleDumpFile <文件名> 使用指定的MiniDump文件启动BlueScreenView。（用于/ LoadFrom 3）
/ ComputersFile <文件名> 指定计算机列表文件名。（当LoadFrom = 2时）
/ LowerPaneMode <1-3> 以指定模式启动BlueScreenView。1 =所有驱动程序，2 =仅在堆栈中找到的驱动程序，3 = XP风格的蓝屏。
/ stext <文件名> 将蓝屏崩溃列表保存到常规文本文件中。
/ stab <文件名> 将蓝屏崩溃列表保存到制表符分隔的文本文件中。
/ scomma <文件名> 将蓝屏崩溃列表保存到以逗号分隔的文本文件（csv）中。
/ stabular <文件名> 将蓝屏崩溃列表保存到表格文本文件中。
/ shtml <文件名> 将蓝屏崩溃列表保存到HTML文件（水平）中。
/ sverhtml <文件名> 将蓝屏崩溃列表保存到HTML文件（垂直）中。
/ sxml <文件名> 将蓝屏崩溃列表保存到XML文件中。
/ sort <列> 此命令行选项可与其他保存选项一起使用，以按所需列进行排序。如果未指定此选项，则列表将根据您在用户界面中进行的最后排序进行排序。<column>参数可以指定列索引（第一列为0，第二列为1，依此类推）或列名，例如“错误检查代码”和“崩溃时间”。如果要以降序排序，则可以指定“〜”前缀字符（例如：“〜Crash Time”）。如果要按多列排序，可以在命令行中输入多个/ sort。
示例：
BlueScreenView.exe / shtml“ f：\ temp \ crashes.html” / sort 2 / sort〜1
BlueScreenView.exe / shtml“ f：\ temp \ crashes.html” / sort“错误检查字符串” / sort“〜崩溃时间”
/ nosort 当您指定此命令行选项时，列表将被保存而不会进行任何排序。WinDbg
WinDbg 是 Windows 调试工具中包含的内核模式和用户模式调试器。Windbg是在windows平台下，强大的用户态和内核态调试工具。相比较于Visual Studio，它是一个轻量级的调试工具，所谓轻量级指的是它的安装文件大小较小，但是其调试功能，却比VS更为强大。它的另外一个用途是可以用来分析dump数据。
设置转储文件
转储文件是程序记录的一份信息，可能包含一些配置信息或者内存数据，一般在出错时便于记录程序在此时的状态。
此电脑——右键属性——系统信息——高级系统设置——启动故障和恢复——设置——系统失败
或
打开 控制面板>系统>高级系统设置>高级>启动和故障恢复>设置，写入调试信息>选择 “小内存转储（256KB）”，路径选择默认，确定并重启计算机。
转储文件可以在任务栏搜索高级系统设置来配置
- 小内存转储（256KB）：
只记录了系统崩溃时正在运行的进程的基本信息和崩溃的线程的堆栈信息。占用空间小，适合快速分析。
- 核心内存转储：
包含了核心内存（内核模式下的内存）中的信息，包括操作系统和驱动程序的状态，但不包括用户模式进程的完整信息。适合用于分析操作系统或驱动程序的故障。
- 完全内存转储：
记录了系统崩溃时所有物理内存的内容。文件较大，适用于深入分析，尤其是需要重现问题时。
- 自动内存转储：
一种介于小内存转储和核心内存转储之间的方式。它记录内核模式内存的所有重要信息，适合大多数问题的分析，并且生成的文件相对较小。
- 活动内存转储：
记录系统当前运行的进程和活动内存信息，主要用于分析活跃的进程和线程状态。
在需要分享时，务必设置小内存转储，防止信息泄露。接下来的教程以小内存转储为例！
安装WinDbg
通过store即可安装
符号表设置
符号表是WinDbg的关键数据库，没有符号表，WinDbg无法分析出更多的问题的原因，符号表设置方法如下：
老版设置
首先，Ctrl+S弹出符号表设置窗口（点击 file->Symbol File Path）。
然后，输入：SRV*C:\Symbols*https://msdl.microsoft.com/download/symbols，点击OK.
WinDbg新版设置
File——Settings——Debugging Settings——Debugging paths——Symbol Path中输入：
SRV*C:\Symbols*https://msdl.microsoft.com/download/symbols
或在命令窗口中输入：
.sympath SRV*C:\Symbols*https://msdl.microsoft.com/download/symbols验证符号路径是否设置成功：
.sympath重新加载符号：
.reload /f获取.dump文件
文件一般在此处：C:\Windows\Minidump
使用windbg打开dump文件即可（可使用【Ctrl+D】快捷键来打开，或者点击WinDbg界面上的【File=>Open Crash Dump…】）！
当你想打开第二个dmp文件时，可能因为上一个分析记录未清除，导致无法直接分析下一个dmp文件，此时你可以使用快捷键【Shift+F5】来关闭上一个dmp分析记录。
分析
如果你需要分析本机的dump文件，可能会遇到权限问题，这时候是无法直接打开的！
可以使用管理员权限运行windbg，然后打开文件。
点击左上角文件
注意：打开时可能会先获取pdb文件(用于显示函数名等)，如果下载速度比较慢，可以断网再打开，不影响现在使用。
简单分析
第一个关键信息：System Uptime（开机时间）
通过观察这个时间你就可以知道问题是在什么时候出现的，例如时间小于1分钟基本可以定位为开机蓝屏，反之大于一分钟则可证明是上机后或玩的过程中出现问题了。
接下来用一个简单的例子来学习简单的dmp分析，下图中System Uptime: 0 days 0:14:23.581，意思是0天(days)0小时14分23秒581毫秒时出现蓝屏了，看来是上机没多久就蓝屏了。
第二个关键信息：Probaly caused by（造成蓝屏可能的原因）
这个信息是相对比较重要的一个信息，如果你运气好的话，通过这个信息基本上可以看到导致蓝屏的驱动或者程序名称了，就像下图一样，初步的分析已经有了结果，Probaly caused by后面显示的是一个名为KiMsgProtect.sys的驱动文件导致蓝屏，这个文件就是恒信一卡通的一个关键驱动。因此蓝屏则很有可能和一卡通有关。
括号中驱动文件名后面的+号代表的是偏移地址，假如多个dmp文件的驱动文件名一样，且偏移地址也一样，则问题原因极有可能是同一个，这个偏移地址与汇编有关，这里不多做介绍。
使用!analyze -v进一步分析
For analysis of this file, run !analyze -v 现在提示我们输入!analyze -v来分析，实际上我们只需要点击这里的!analyze -v即可自动输入。
分析以后，我们先来看上面这一部分：
KERNEL_DATA_INPAGE_ERROR (7a)
The requested page of kernel data could not be read in. Typically caused by
a bad block in the paging file or disk controller error. Also see
KERNEL_STACK_INPAGE_ERROR.
If the error status is 0xC000000E, 0xC000009C, 0xC000009D or 0xC0000185,
it means the disk subsystem has experienced a failure.
If the error status is 0xC000009A, then it means the request failed because
a filesystem failed to make forward progress.
Arguments:
Arg1: ffff90093458d060, lock type that was held (value 1,2,3, or PTE address)
Arg2: ffffffffc000000e, error status (normally i/o status code)
Arg3: 0000000202568860, current process (virtual address for lock type 3, or PTE)
Arg4: fffff805304dc3bb, virtual address that could not be in-paged (or PTE contents if arg1 is a PTE address)
这里面混杂着状态信息和提示，根据第一行错误代码，我们可以在这里找到解释
Bug 检查 0x7A KERNEL_DATA_INPAGE_ERROR – Windows drivers | Microsoft Learn
我们根据错误代码推断出，无法将虚拟内存写入内存中，其中虚拟内存(分页文件)在硬盘上，说明硬盘或者内存有问题！
Arguments:
Arg1: ffff90093458d060, lock type that was held (value 1,2,3, or PTE address)
Arg2: ffffffffc000000e, error status (normally i/o status code)
Arg3: 0000000202568860, current process (virtual address for lock type 3, or PTE)
Arg4: fffff805304dc3bb, virtual address that could not be in-paged (or PTE contents if arg1 is a PTE address
我们可以看到，第一个参数是一个地址，并不是一个状态数字，所以我们可以在错误解释中找到这个
| 参数 | 说明 |
|---|---|
| 1 | 页表项 (PTE) 的地址 |
| 2 | 错误状态（通常是 I/O 状态代码） |
| 3 | PTE 内容 |
| 4 | 故障地址 |
我们重点查看参数2，这是一个错误状态，可能有用：ffffffffc000000e
省略前面占位的f，我们可以得到c000000e
在原因中就有结果：
0xC000000E 或 STATUS_NO_SUCH_DEVICE 表示硬件故障或驱动器配置不正确。 检查电缆，并使用驱动器制造商提供的诊断实用工具检查驱动器。 如果使用的是较旧的 PATA (IDE) 驱动器，此状态代码可能表示主/从驱动器配置不正确。
此时我们基本上已经得出问题原因了，是硬盘硬件故障！
之后的一部分有一些数据，这些数据的简介：
- PEB is paged out：指进程环境块（PEB）已经被换出到磁盘，无法直接访问。这可能意味着崩溃发生时，某些内存页不在物理内存中。
这一部分列出了一些关键的分析数据，包括：
- Analysis.CPU.mSec：崩溃时 CPU 使用的时间（毫秒）。
- Analysis.Elapsed.mSec：从系统开始崩溃到记录转储的时间（毫秒）。
- Analysis.IO.Other.Mb：其他 I/O 操作的数据量（MB）。
- Analysis.IO.Read.Mb：读操作的数据量（MB）。
- Analysis.IO.Write.Mb：写操作的数据量（MB）。
- Analysis.Init.CPU.mSec：初始化时 CPU 使用的时间（毫秒）。
- Analysis.Memory.CommitPeak.Mb：崩溃时的内存峰值使用（MB）。
- Bugcheck.Code.LegacyAPI 和 Bugcheck.Code.TargetModel：表示错误检查代码，通常用于标识崩溃原因。0x7a 表示一个特定类型的错误，通常与 I/O 或设备驱动相关。
- 这些属性提供有关转储文件的元数据，例如：
- Dump.Attributes.LastLine：转储操作完成的信息。
- Dump.Attributes.ProgressPercentage：转储进度百分比（此处为 0，表示转储已完成）。
- Dump.Attributes.KernelGeneratedTriageDump：表示是否生成了内核故障转储。
这一部分的信息与虚拟化相关，显示了 Hyper-V（微软的虚拟化技术）的状态和配置，包括是否启用了某些功能（如 CPU 管理、嵌套虚拟化等）。
再看后面：
BUGCHECK_CODE: 7a
BUGCHECK_P1: ffff90093458d060
BUGCHECK_P2: ffffffffc000000e
BUGCHECK_P3: 202568860
BUGCHECK_P4: fffff805304dc3bb
FILE_IN_CAB: 100724-4796-01.dmp
DUMP_FILE_ATTRIBUTES: 0x21808
Kernel Generated Triage Dump
FAULTING_THREAD: ffffe78d32aef080
ERROR_CODE: (NTSTATUS) 0xc000000e - <Unable to get error code text>
DISK_HARDWARE_ERROR: There was error with disk hardware
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: dwm.exe
TRAP_FRAME: fffff884f22766a0 -- (.trap 0xfffff884f22766a0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff884f2276990 rbx=0000000000000000 rcx=ffffe78d31def870
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff805304dc3bb rsp=fffff884f2276830 rbp=fffff884f2276930
r8=0000000000000001 r9=0000000000000001 r10=fffff805830369d0
r11=fffff884f2276798 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na pe nc
win32kbase!CTouchProcessor::CleanupManipulationThreadData+0x4ab:
fffff805`304dc3bb 488d4638 lea rax,[rsi+38h]
Resetting default scope
STACK_TEXT:
fffff884`f2276338 fffff805`8349beea : 00000000`0000007a ffff9009`3458d060 ffffffff`c000000e 00000002`02568860 : nt!KeBugCheckEx
fffff884`f2276340 fffff805`83053e60 : fffff884`00000000 00000000`00000800 fffff884`f22764e0 00000000`00000000 : nt!MiWaitForInPageComplete+0x44a0e6
fffff884`f2276430 fffff805`8301597a : 00000000`00008000 00000000`00000002 00000000`c0033333 fffff805`82e00000 : nt!MiIssueHardFault+0x25c
fffff884`f2276530 fffff805`83482ecb : 00000000`00000fff fffff805`83c176c0 00000001`615ba2f0 00000001`615ba2f4 : nt!MmAccessFault+0x46a
fffff884`f22766a0 fffff805`304dc3bb : ffff9009`3ad256e0 ffff9009`390c59c0 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x38b
fffff884`f2276830 fffff805`30787bcc : ffff9009`3ad256e0 ffff9009`3ad256e0 ffff9009`3ad256e0 00000000`00000000 : win32kbase!CTouchProcessor::CleanupManipulationThreadData+0x4ab
fffff884`f2276b00 fffff805`3046b152 : fffff884`f2276c70 ffff9009`3ad256e0 ffff9009`3ad256e0 00000000`00000000 : win32kfull!xxxCleanupThreadPointerInputInfo+0x4c
fffff884`f2276b30 fffff805`3046e734 : ffff9009`3ad256e0 fffff805`30543801 fffff805`30543801 ffff9009`3ad258b0 : win32kbase!xxxDestroyThreadInfo+0x24e
fffff884`f2276cb0 fffff805`30667cdd : 00000000`00000001 00000000`00000001 ffffe78d`32aef080 00000000`00000000 : win32kbase!UserThreadCallout+0x1d4
fffff884`f2276d20 fffff805`30411091 : 00000000`00000001 00000000`00000001 fffff884`f22770b0 fffff884`f22770b0 : win32kfull!W32pThreadCallout+0x6d
fffff884`f2276d50 fffff805`303e594a : 00000000`00000001 00000000`00000001 fffff884`f22770b0 00000000`00000000 : win32kbase!W32pThreadCallout+0x35
fffff884`f2276d80 fffff805`303e57ef : 00000000`00000000 fffff884`f2277060 00000000`00000000 00000000`00000001 : win32kbase!W32CalloutDispatchWorker+0x14e
fffff884`f2276ee0 fffff805`30201547 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : win32kbase!W32CalloutDispatch+0xf
fffff884`f2276f10 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : win32k+0x1547
SYMBOL_NAME: win32kbase!CTouchProcessor::CleanupManipulationThreadData+4ab
MODULE_NAME: win32kbase
IMAGE_NAME: win32kbase.sys
IMAGE_VERSION: 10.0.26100.1912
STACK_COMMAND: .process /r /p 0xffffe78d32603080; .thread 0xffffe78d32aef080 ; kb
BUCKET_ID_FUNC_OFFSET: 4ab
FAILURE_BUCKET_ID: 0x7a_c000000e_win32kbase!CTouchProcessor::CleanupManipulationThreadData
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {14abc725-af6f-6c1a-fe90-2c13c90000ae}
Followup: MachineOwner这里面包含了一些错误发生时正在运行的进程和模块。
PROCESS_NAME: dwm.exe
MODULE_NAME: win32kbase
IMAGE_NAME: win32kbase.sys
我们可以得知，当时运行的进程是dum.exe(窗口管理器)，当时调用的模块是win32kbase.sys
得出结论
这个错误可能是由于硬盘出错导致的问题，因为虚拟内存刚好在该硬盘上导致系统崩溃。
尝试修复
在该问题中，我采用了以下方法：
1.修改虚拟内存到其他硬盘。
2.使用DiskGenius进行坏道检测。
此时发现，硬盘时不时复位，导致操作超时。
实际上，这个问题是因为电源供电不足导致的，更换更大功率的电源即可。
现在，问题已经修复。
技巧
在这里获取错误码列表：https://learn.microsoft.com/zh-cn/windows-hardware/drivers/debugger/bug-check-code-reference2
使用ctrl+F查找错误代码，点击名称即可跳转到详情页面！
请按照该教程顺序分析，不要一上来就看进程名，这是没有效果的。
如系统无法启动，可以尝试进入安全模式或者使用pe系统启动，此时可以使用旧版windbg分析。
私信站长
暂无评论内容