蓝屏这东西，真的是一瞬间的事情。前一秒还在敲代码或者打游戏，下一秒整个屏幕变成刺眼的蓝色，白色小字一行行往下滚，然后电脑重启，桌面干干净净，好像什么都没发生过。但是那个蓝屏代码、那个崩溃瞬间的恐惧感，是真实存在的。我处理过太多太多蓝屏的案例，对于绝大多数情况来说，蓝屏不等于硬件报废，更不等于必须要重装系统。这篇文章我不讲玄学，不看面相，就讲怎么一步步从蓝屏里满血复活，先搞懂蓝屏到底是怎么发生的，再教你怎么用事件查看器和Windbg这类工具把罪魁祸首揪出来，最后给出从软件到硬件的一整条修复路线。不管你是第一次遇到蓝屏的小白，还是被某个蓝屏代码反复折磨的进阶用户，这篇文章都值得你看完，里面包含大量我用实际维修经验换来的排查细节和避坑技巧。
1. 蓝屏不是末日：先搞清楚它到底在干什么
1.1 蓝屏的本质是Windows在紧急刹车
蓝屏的学名叫做错误检查（Bug Check），微软官方叫它Stop Error。你可以把Windows想象成一辆正在高速行驶的车，正常情况下发动机、刹车、方向盘各司其职，但是当系统检测到某个底层组件的状态已经到了完全不可信的程度——比如驱动程序试图写入非法内存地址、某个关键系统进程无响应、存储设备返回了无法理解的数据——继续运行下去只会导致更严重的数据损坏甚至硬件损伤，于是Windows狠心踩下刹车，整辆车直接熄火。
这个“熄火”的动作就是蓝屏。
很多用户不理解，觉得蓝屏是Windows没用的表现。恰恰相反，蓝屏是Windows最后的保护机制。在Windows早期时代，内核态程序出问题往往直接造成系统静默死机或者数据静默损坏，那种问题比蓝屏可怕得多。蓝屏的价值在于它强制停止了系统，同时尽可能把崩溃原因写进内存转储文件（dmp），留给后来者排查。这就像飞机失事后的黑匣子——虽然坠机很遗憾，但黑匣子里的数据能告诉我们为什么坠机，从而避免下一次。
1.2 为什么驱动是蓝屏的头号嫌疑人
Windows操作系统的架构分内核态（Kernel Mode）和用户态（User Mode）。浏览器、办公软件这些普通程序跑在用户态，权限有限，即使崩溃了也就是程序自己退出去，弹个“无响应”，不会带崩整个系统。但设备驱动、杀毒软件的底层过滤驱动、虚拟化平台的内核扩展这些代码，跑在内核态，拥有最高权限，可以直接访问硬件和内存。
内核态代码一旦出错，比如访问了空指针、陷入死锁、把只读内存给写了，后果就是系统整个崩溃。这也是为什么蓝屏信息里你能看到很多结尾是.sys的文件——这些文件九成以上都是内核态驱动。
做个不太精确但好懂的类比：用户态程序是房客，内核驱动是物业的电工。房客在家里搞坏了自己的电器，最多自己屋里跳闸；电工在总配电房接线接错了，整栋楼都得停电检修。蓝屏就是“全楼停电”的瞬间，而这个电工通常就是我们排查时要重点盘问的对象。
1.3 蓝屏信息里的四要素，你只需要看这四个
每次蓝屏，屏幕上会滚动出不少信息。对普通人来说不需要全部看懂，但有几个关键信息一定要抓住：
| 要素 | 在哪看 | 怎么理解 |
|---|---|---|
| 错误代码（Bug Check Code） | 通常是十六进制，形如0x0000001E或以0xC000021A格式出现 | 这是蓝屏的“病名”，微软有官方文档逐条解释 |
| 失败的操作模块 | 形如dxgmms2.sys、ntoskrnl.exe | 这是系统认为“肇事”的文件，但注意未必是真凶 |
| 参数信息 | 错误代码旁边的四个十六进制值 | 给开发者和高级排查者看的关键线索 |
| 内存转储进度 | 显示“收集到的信息”百分比 | 决定你能否拿到dmp文件进一步分析 |
这里要特别纠正一个普遍误区：屏幕上显示的.sys文件名不一定就是出问题的驱动，它可能只是“崩溃发生时正在运行的驱动”。真正的出错点往往需要通过分析dmp文件才能确定。这就像警察赶到事故现场，A车和B车撞了，A车的司机说对方全责，现场看起来也是B车停在路中间，但定责还要靠行车记录仪——在蓝屏领域，Windbg分析dmp文件就是那个行车记录仪。
2. 拿到蓝屏先做这三件事：别急着重装系统
2.1 第一件事：拍照，然后强制重启一次
很多人遇到蓝屏后的第一反应是慌了，然后按电源键重启，甚至有人立刻掏出U盘开始重装系统。且慢，先拍照。现代Windows的蓝屏界面虽然简化了，但错误代码、失败模块这些关键信息都还在。手机随手拍一张，蓝屏停留时间足够你拍完照。拍照不是为了发朋友圈，而是为了在你后续排查时提供方向。
拍完照再看情况重启。如果蓝屏是偶发的，重启后能正常进系统，那就赶紧把重要文件备份一份到网盘或移动硬盘。如果重启后依然蓝屏、能进安全模式但正常模式不行，那说明问题已经比较严重了，但依然不要立刻重装——先尝试进入安全模式，在安全模式下系统只加载最基本的驱动，如果安全模式能稳定运行，说明大概率是第三方驱动或软件冲突，而不是核心硬件层面的问题。
2.2 第二件事：打开“事件查看器”和“可靠性监视器”
重启进入系统后，很多人就不知道下一步干嘛了。记住两个Windows自带工具的名号：事件查看器（Event Viewer）和可靠性监视器（Reliability Monitor）。
事件查看器的打开方式：按Win + X，选择“事件查看器”，然后依次展开“Windows日志”→“系统”。在右侧点击“筛选当前日志”，把ID过滤条件设为41（系统异常重启）、1001（蓝屏记录，Windows Error Reporting）和6008（意外关机）。这三个事件ID组合起来，能帮你确认蓝屏发生的具体时间，以及大概的错误模块。
可靠性监视器更直观：在开始菜单里直接搜“可靠性历史记录”或运行perfmon /rel。它会以时间线的形式展示系统每周的稳定性情况，蓝屏日子直接标记为一个红叉图标，点进去就能看到具体的故障详情，还包括Windows报告的问题摘要。这个工具是全图形界面的，小白也能看明白，强烈建议养成定期看一眼的习惯。
2.3 第三件事：回溯蓝屏前5分钟你做了什么
这一步被90%的人忽略，但恰恰是最关键的破案线索。仔细回忆一下：蓝屏前你正在干什么？是玩游戏、渲染视频，还是开着虚拟机？最后一次安装的软件或驱动是什么时候？有没有插拔U盘、外接显示器、更换硬盘？
我在实操中发现，绝大多数蓝屏案件都能靠这一问锁定嫌疑范围。比如玩游戏时蓝屏，重点怀疑显卡驱动和电源供电；虚拟机一开就蓝屏，重点怀疑虚拟化设置和内存分配；装完某个软件/驱动后蓝屏，重点怀疑兼容性和驱动冲突；改动BIOS之后蓝屏，重点怀疑启动模式和磁盘控制器设置。有了这个主观判断，后面查代码、查dmp文件、做排查测试才有方向感，不然就是大海捞针。
3. 高频蓝屏代码逐个拆：我看到代码就知道该查哪
3.1 0xc000021a：关键系统进程挂了，但别急着重装
这个代码在热搜里出现了好几次。0xC000021A的意思是“用户态关键进程意外终止”，也就是说系统要求必须常驻的某个用户态进程崩了，导致内核选择蓝屏。比较知名的肇事场景包括：Winlogon.exe、Csrss.exe等系统进程被第三方软件注入崩溃，或者是安全软件与系统组件发生冲突。
应对思路分几步走。第一步进安全模式，看看能不能正常运行sfc /scannow（系统文件检查器）和DISM /Online /Cleanup-Image /RestoreHealth，修复系统文件完整性。第二步，如果修复无效，回忆蓝屏前是否安装过某个杀毒软件或系统优化工具，进安全模式卸载它。第三步，检查系统盘剩余空间是否过低，C盘爆满也会导致关键进程无法正常写入临时文件从而崩掉。做完这三步，大多数情况下这个问题都能缓解。
3.2 kernel data inpage error：存储子系统在喊救命
KERNEL_DATA_INPAGE_ERROR（通常代码为0x0000007A）这个蓝屏非常典型——内核想要从页面文件或某个磁盘文件中读取数据，但无论怎么重试都读不出来。这就好比图书馆的系统显示某本书存在，但管理员去找了几次，书架上没有，仓库里也没有，系统只能当场崩溃。
原因主要在三处：内存条不稳定导致写入磁盘的数据本身就是坏的、硬盘（尤其是机械硬盘）出现坏道或SATA数据线接触不良、SSD的固件问题。排查路径清晰：先用Chkdsk检查磁盘坏道（chkdsk /f /r），再用内存诊断工具测试内存（Windows自带的“Windows内存诊断”或MemTest86），最后换一根SATA线或换个M.2插槽试试。很多用户一看到这个代码就换硬盘，其实内存条不稳定的概率并不低，我见过不少案例是内存原因导致这个蓝屏。
3.3 unexpected store exception：藏着SSD、AHCI与驱动三者的博弈
UNEXPECTED_STORE_EXCEPTION（代码0x00000139）是Windows 10/11时代相当高频的蓝屏代码，尤其是NVMe固态硬盘普及之后。“Store”在Windows驱动模型里指存储栈，这个异常意味着存储栈收到了一个意料之外的错误，通常是SSD驱动、NVMe控制器和系统存储驱动之间的协作出了问题。
说人话：SSD本身未必坏了，但Windows和SSD之间的某个中间环节沟通失灵了。常见原因包括：过老的NVMe驱动与新版Windows不兼容、SSD固件有Bug、BIOS里磁盘模式设置不当（比如同时涉及Intel Rapid Storage Technology和AHCI）、系统盘开启的写缓存策略与硬件特性冲突。维修思路是：先更新主板芯片组驱动和Intel/AMD存储驱动，然后去SSD官网查固件更新，如果改了主板BIOS的磁盘模式（IDE改AHCI、AHCI改RAID）就检查这个方向。另外，有时候把系统设置里的“快速启动”关掉也能减少这类蓝屏的发生频率——快速启动实际上是把内核会话休眠起来，下次开机时恢复，这个过程对存储系统压力非常大。
3.4 bad system config info：注册表和驱动配置的错位
BAD_SYSTEM_CONFIG_INFO（代码0x00000074）的出现，意味着系统配置信息（主要是注册表里的系统配置单元）有损坏，或者某个驱动要求在系统启动早期加载一个配置项，但配置内容不完整。
触发场景非常典型：一是硬件配置没有任何变化，但某次异常断电后重启就蓝屏；二是用户手动用“系统配置”（msconfig）关闭了某个服务导致配置错乱；三是某些清理软件的注册表清理功能把关键键值删了。
处理思路：优先尝试高级启动→疑难解答→高级选项→“启动设置”→重启后选择进入“启用低分辨率视频模式”，或者干脆“上次的正确配置（高级）”——这个选项在Windows 10之后被移到故障恢复菜单里了，操作起来跟以前不大一样，但依然有效。如果这些都不行，再考虑用系统还原点（如果之前有创建）、用安装U盘执行启动修复，最后才考虑PE环境下备份数据并重装系统。
3.5 带sys后缀的蓝屏：驱动级问题要从这些思路下手
热搜词里出现了好几个具体的sys文件：dxgmms2.sys、ace base.sys、rwdrv.sys、haspusersetup等。简单拆一下：
dxgmms2.sys：显卡相关，是DirectX图形内核模式驱动的组成部分。出现这个文件关联的蓝屏，优先考虑显卡驱动更新/回滚，用DDU（Display Driver Uninstaller）彻底清除旧驱动后重装，同时排查显卡温度、供电、超频稳定性。ace base.sys：这个文件跟反外挂软件有关。出现它关联的蓝屏，先卸载反外挂组件或者调整它跟杀毒软件的兼容性，不要在游戏运行时同时挂一堆安全软件。rwdrv.sys：来自磁盘加密或数据保护类软件（比如某些虚拟光驱/写保护工具）。这类第三方内核驱动兼容性出错，优先考虑升级该软件版本或干脆卸载。haspusersetup：严格说是加密狗驱动相关的安装组件，常见于专业软件（工程软件、设计软件）使用加密狗时。安装新版驱动或用官方提供的卸载清理工具彻底重装，是解决这类蓝屏的主要办法。
看sys文件有个通用规则：先用搜索引擎查这个文件归属哪家软件，然后定向处理那个软件的驱动更新与卸载重装。记住，蓝屏关联的文件相当于“现场指纹”，它指向的区域可能只是崩溃点，但顺着这个区域深挖，往往能找到埋着的雷。
4. 虚拟机一开就蓝屏：这类问题的专属排查思路
4.1 为什么跑虚拟机更容易触发蓝屏
热搜词里关于虚拟机的蓝屏问题特别密集，比如“vmware打开虚拟机就蓝屏重启”、“虚拟机安装linux蓝屏”。这背后的技术原因非常值得展开讲一下。
虚拟机软件（VMware Workstation、VirtualBox、Hyper-V等）本身为了获得接近物理机的性能，会向Windows内核注入自己的驱动：VMware就有vmx86.sys、vmnet*.sys等驱动模块，VirtualBox也有VBoxDrv.sys等。这些驱动在内核态运行，负责处理CPU虚拟化指令、内存管理、网络桥接。一旦它们和Windows自身的虚拟化功能（Hyper-V、内核隔离、基于虚拟化的安全性，简称VBS）产生抢占或冲突，蓝屏就一触即发。
Windows 10/11越来越多地默认开启“内核隔离”和“内存完整性（Memory Integrity）”功能，这个功能机制上跟虚拟机软件的驱动加载方式有天然冲突，因为内存完整性会在代码层面对所有内核态驱动做签名和行为验证，虚拟机驱动有时候无法满足要求，一加载就触发蓝屏。
4.2 排查步骤：关快速启动、开VT-x、调显存、更新驱动
按照下面的顺序逐步排查，大多数虚拟机蓝屏都能解决：
- 第一优先：确认BIOS里开启了“VT-x/AMD-V”虚拟化功能。现代BIOS基本都默认开启，但有些主板升级BIOS之后会被重置为关闭状态。虚拟化指令没开启，虚拟机在加载CPU虚拟化模块时轻则报警、重则蓝屏。
- 第二步：把Windows的“内存完整性”临时关掉看看。路径在“Windows安全中心”→“设备安全性”→“内核隔离详情”→“内存完整性”，关闭后重启。如果这样虚拟机就稳定了，说明确系冲突，可以持续关闭（不过非虚拟化用户不建议长期关，安全收益还是有价值的）。
- 第三步：关闭“快速启动”。控制面板→电源选项→选择电源按钮的功能→更改当前不可用的设置→取消勾选“启用快速启动”。这一步能解决大量“电脑放了几个小时后一开虚拟机就蓝屏”的问题。
- 第四步：升级虚拟机软件到最新版，或者换一个版本试试。比如VMware Workstation用户，旧版在新版Windows上很容易蓝屏，升级到最新版后问题消失的案例占大多数。
- 第五步：调整虚拟机配置。给虚拟机分配的内存不要超过物理机内存的50%，尤其不要把全部内存都给虚拟机——Windows自己也需要足够内存做磁盘缓存，内存分配极端不均衡会导致系统内存管理模块压力过大。
4.3 特别提醒：BIOS里改AHCI/RAID后蓝屏是另一个坑
热搜词里“系统改ahci就蓝屏”也是一个高频问题。很多人为了给固态硬盘开启NCQ或为了组RAID阵列，跑进BIOS把SATA模式从IDE改成AHCI，结果Windows一启动就蓝屏。这个蓝屏原理比较特殊：Windows在安装时根据当前磁盘控制器模式加载了对应的驱动，系统注册表里的启动配置也是按这个模式配的。你突然改BIOS模式，系统启动早期找不到匹配的磁盘驱动，自然读不了系统盘。
解决办法不是改回IDE然后从此放弃，而是先让系统安全地完成硬盘控制器驱动的改用。推荐流程：先进入BIOS改回原来的模式，正常进入系统，打开设备管理器，找到“IDE ATA/ATAPI控制器”或“存储控制器”，更新驱动为“标准SATA AHCI控制器”；然后在运行里输入msconfig，勾选“引导”选项卡里的“安全引导”（建议最小化），重启进BIOS改成AHCI模式；重启后Windows会以安全模式加载新的AHCI驱动，再进msconfig关掉安全引导，再次重启即可满血进入AHCI模式。这个操作就是绕开“启动时换驱动”的死锁，先让系统在安全模式下学会用新驱动，再回到正常模式。
1. 终极破案工具：Windbg分析dump文件
1.1 先开启小内存转储，否则没有破案证据
分析蓝屏最专业的路线不是看蓝屏屏幕上的那一两行字，而是分析系统在蓝屏瞬间保存下来的内存转储文件（dump文件）。但这里有个坑：Windows默认设置可能是“无内存转储”，也就是说，蓝屏发生后系统什么都没留下。所以，想在蓝屏后拿到证据，必须提前设置。
设置路径：右键“此电脑”→“属性”→“高级系统设置”→“启动和故障恢复”→“设置”。在这个窗口里，核心选项是“写入调试信息”。对于普通排查用户，我建议选“小内存转储（256KB）”，因为文件体积小、生成速度快、后续打开也方便，并且它已经包含了导致崩溃的关键线程栈和错误参数。如果做更深入的内核分析，可以选择“核心内存转储”或“自动内存转储”，但这类文件可能几个GB，得保证系统盘有足够空间。
转储文件默认存放在C:\Windows\Minidump目录。如果你没有改过这个路径，蓝屏后会在这个目录下生成后缀为.dmp的文件，这就是破案的核心证据。顺便提醒一句：部分第三方安全软件会把dump文件当病毒隔离或者直接删除，如果发现没有生成dmp，除了检查设置，也要看看安全软件的行为日志。
1.2 Windbg分析流程：从加载符号到一句话结论
Windbg是微软官方提供的调试器，专业到有些劝退新手，但蓝屏分析其实只需要掌握几个固定命令，完全可以拿来当“傻瓜验尸工具”。
第一步，安装Windbg。现在官方推荐通过Windows商店安装“Windows SDK”然后挑选“Debugging Tools for Windows”，更简单的做法是直接在商店搜“WinDbg”安装新版本（WinDbg Preview）。新版本界面友好很多。
第二步，打开dmp文件：把C:\Windows\Minidump里的dmp文件拖到Windbg窗口里，它会自动进入分析会话。
第三步，配置符号路径。在命令框里输入：
.sympath srv*C:\Symbols*https://msdl.microsoft.com/download/symbols然后输入.reload（重新加载符号）。符号文件是Windows系统各模块的“名称对照表”，没有它Windbg只能看到一堆地址和数字，加载符号后才能显示具体的函数名、模块名。首次加载符号会下载几百MB文件，需要耐心等。
第四步，也是最重要的一步，输入：
!analyze -v这个命令是自动分析的“核心理事”，它会自动检查崩溃代码、遍历内核栈、定位崩溃时正在执行代码的模块，最后给出一个可读的结论。执行结果里重点看这几个字段：MODULE_NAME（嫌疑模块名）、FAULTING_MODULE（可能出错的模块）、STACK_TEXT（崩溃线程的调用栈）、IMAGE_NAME（崩溃时正在加载的镜像文件）。如果MODULE_NAME正好对应某个驱动文件，直接去查这个驱动的归属方、版本更新情况即可。
1.3 一个虚构案例演示：日志里“聊天”出来的凶手
我说一个基于日常经验模拟的案例，帮助大家理解Windbg输出到底长什么样。
假设dmp文件分析后，STACK_TEXT的末尾几行显示dxgmms2.sys+0x1a3b0、wdmaud.sys+0x1a3b0之类的，MODULE_NAME指向dxgmms2，而IMAGE_VERSION对应版本是2021年发布的很旧版本。那分析方向就很清晰：这是显卡驱动相关模块在崩溃时执行到的一个函数，大概率是驱动版本过旧或损坏。
此时处理手段有两个优先级：第一优先，去显卡品牌官网下载最新稳定版驱动，用DDU在安全模式下彻底清理旧驱动后安装；第二优先，如果最新版驱动安装后蓝屏依旧，看事件查看器的崩溃时间是否跟某个软件运行时间重合。比如案例中的时间是用户在播放视频时崩溃，则重点排查音频驱动（wdmaud.sys也是音频相关），因为dxgmm和音频驱动可能同时操作某个共享资源导致竞争条件。一句话，!analyze -v只是把嫌疑范围圈住，后续的推理还得结合使用场景和各方线索，这就是实战相对“验尸工具”最有意思的地方。
2. 满血复活实战路线图：从软修复到硬排查
2.1 系统层面：sfc、DISM与系统还原
蓝屏发生后的修复之路，我建议严格按照“从软到硬、从系统到硬件”的顺序来，这样能节省大量排查成本，也能保护不该被重装或更换的硬件。
系统文件完整性检查是第一步，命令行里输入：
sfc /scannow这个命令会扫描所有受保护的系统文件，如果发现损坏且源文件可用，它会自动从缓存中恢复。但sfc有个弱点：当损坏发生在“系统映像源”本身时，它修复不了。那就要先用DISM修复映像源，再跑sfc。DISM命令如下（对在线系统）：
DISM /Online /Cleanup-Image /RestoreHealth建议先DISM后sfc，顺序反了的话，sfc修复成功率会打折扣。整个操作需要一个网络畅通的环境，DISM可能需要从Windows Update下载正确的源文件。
如果连DISM都报错，或者蓝屏频率仍然很高，考虑系统还原：在“设置”→“更新和安全”→“恢复”→“高级启动”→“立即重新启动”→“疑难解答”→“高级选项”→“系统还原”。系统还原相当于把系统文件、驱动程序、注册表关键项恢复到一个过去的正常时间点，不影响个人文件。前提是你平时有创建还原点的习惯，或者系统在关键事件（比如安装驱动）之前自动创建了还原点。
2.2 驱动层面：DDU清理与常用驱动更新策略
驱动冲突是蓝屏第一大来源，所以系统文件修复之后，必须系统性地整理驱动。以前我推荐小白直接去“设备管理器”一个个更新，后来我发现最高效的做法是分类处理：
- 显卡驱动：别用设备管理器的“更新驱动”按钮（它找的往往不是最新的），去NVIDIA、AMD或Intel官网下载对应型号的最新正式版驱动，或者用品牌机/笔记本厂商官网的驱动。高级用户使用DDU（Display Driver Uninstaller）在安全模式下彻底卸载旧驱动后再装新版，能避开很多残留冲突。
- 主板芯片组驱动：去主板品牌官网下载Intel/AMD芯片组驱动，这是很多人忽略的一个驱动类别。芯片组驱动负责管理USB、SATA、PCIe总线，老旧不兼容的版本一样可以造成莫名其妙的蓝屏。
- 网卡/声卡驱动：优先用主板官网推荐版本，如果不稳定，试试回退到微软自带的通用驱动，有时反而更稳。
我遇到过一个反复蓝屏的案例，最后发现问题是用户在官网下载了“最新的”网卡驱动，但那个版本有已知内存泄漏缺陷。这里特别提醒：驱动追求“最新”不代表“最稳定”，生产力和游戏用途尽量选用“WHQL认证+近一年内的稳定版本”，不要追着Beta版和体验版跑。
2.3 硬件层面：内存、硬盘、电源与散热专项排查
软件排查走到了死胡同，才轮到硬件登场。硬件排查也有明确的优先级顺序。
内存测试排第一。内存条是蓝屏的主要物理元凶，而且它的故障很隐蔽——明明能开机、能跑应用，但一高负载就蓝屏，代码五花八门。用Windows自带的“Windows内存诊断”或者U盘引导的MemTest86，跑至少2遍完整测试，只要出现一个error，就直接判断内存故障。内存故障的处理就是替换或者重新插拔、清理金手指、换卡槽。频率上，我建议开机自检正常就做一次内存诊断，比反复装系统靠谱得多。
硬盘测试排第二。用CrystalDiskInfo查S.M.A.R.T.状态，重点关注“C5重新分配扇区计数”和“05损坏扇区计数”。如果数值非零，尤其是持续增长，这就是硬盘在逐渐死去，赶紧备份数据，更换硬盘。SSD还需关注固件版本，去官网查询是否有重大Bug更新——某些早期型号的SSD固件会因为掉电导致主控锁定只读模式，表现就是蓝屏后无法正常启动。
电源与散热排第三。高负载蓝屏（比如大游戏、渲染）大概率跟供电和温度有关。用AIDA64、HWiNFO这类传感器工具记录满载时的CPU和GPU温度，观察到超过95℃就该清灰换硅脂了。电源问题更难查，如果负载一高就蓝屏，而内存硬盘显卡驱动都排除了，不妨借一个同功率或更高功率的电源交叉替换测试。
2.4 重装系统的正确姿势：保留数据的前提下重获新生
如果以上所有排查都做完了，蓝屏依然频繁，最后才轮到“重装系统”这个终极手段。但重装系统也要有点技术含量，不应该无脑格式化重来。
第一步，备份所有个人资料到移动硬盘或网盘，重点包括桌面、文档、下载、浏览器书签、邮箱配置、项目代码本地仓库。第二步，制作官方安装U盘（Windows官方“媒体创建工具”或Rufus），安装时选择“保留我的文件”这个升级安装方式，它会重置系统损坏部分，保留个人文件和部分应用配置，费用低、速度快，适合系统文件损坏不深的场合。如果需要彻底清理，才选择“自定义安装”并删除系统盘所有分区，但这样做之前一定要反复确认重要资料已备份。
重装完成后，先装芯片组驱动→重启，再装显卡驱动→重启，再装网卡、声卡等，每次只做一件事，重启一次，观察几小时。这种“逐个驱动验证”的方法能让你明确知道装了哪个驱动之后系统开始不稳，而不是一次全装完，后面蓝屏了都不知道是谁的锅。这个方法虽然耗时，但避免第二次重蹈覆辙绝对值得。
我在实际维修中见过太多人，蓝屏一次重装系统，装完第二天又蓝屏，结果换了三块硬盘两块内存，最后发现只是某个网卡驱动冲突。如果早几个小时做这一步“逐个验证”，也不至于反复折腾。所以，重建系统后别急着装一堆常用软件，先把驱动体系验证稳定了，再恢复生产力工具的安装，这是恢复系统稳定性最稳妥的路径。
处理蓝屏这件事，我这些年下来最大的体会就是：不要跟蓝屏对着干，也不要怕它，更不要一遇到就重装。蓝屏其实是一份详细的事故报告，它在用最终手段告诉你系统的某个环节出了状况。掌握了读懂报告的方法，把原因找出来并解决掉，系统不仅能恢复，往往还会比之前更稳定、更懂自己的硬件。每次帮别人排掉一个蓝屏，看到对方从崩溃边缘恢复过来，那种踏实感是重装一百遍系统都给不了的。下一次，轮到你屏幕蓝了，深呼吸、拍照、记代码、看事件查看器、开Windbg，一步步把凶手找出来，你会发现自己已经从一个“蓝屏受害者”变成了“系统医生”。
