原创 香依香偎 2026-09-08 12:05 广东

四次蓝屏、200GB 内存和三个 AI —— 一次离谱的故障排查

三连黑屏

周六凌晨到上午，我的笔记本一口气蓝屏了三次。

好吧，严格来说不能叫“蓝屏”——Windows 11 已经把它换成了黑色。颜色变得低调了，杀伤力倒是一点没打折。

一次可以说是偶然，两次可以安慰自己“重启能治百病”，可连续三次就多少有点不讲武德了：我买的是电脑，不是开机动画播放器啊！

于是立刻请出WinDbg，打开MiniDump文件，执行!analyze -v。面对满屏熟悉又陌生的调用栈，我做出了一个非常符合时代精神的决定——把分析结果交给 AI。

第一位会诊专家：Claude。

Claude：显卡驱动，先背一下锅

Claude反应很快：这个错误信息和调用栈已经很明显了！如果不是Android虚拟机或Hyper-V引起的，那大概率就是NVIDIA驱动有问题。别犹豫，升级驱动！

听起来有理有据，而且显卡驱动在蓝屏案里也算“惯犯”。于是我熟练地点开更新，把NVIDIA驱动升到最新版，然后重启电脑。

接下来一整个下午风平浪静。程序能跑，网页能开，电脑也没再表演原地昏厥。

我一度以为案子已经破了，甚至在心里给Claude发了一面“妙手回春”的锦旗。

第四次黑屏

到了晚上，我正美滋滋地在 B 站刷《凡人修仙传》，熟悉的画面突然再次降临：相同的黑屏，相同的错误码，连出场方式都没有一点创新。

第四次了。

看来下午的平静并非问题解决了，只是问题睡了个午觉。

Claude的药只能暂时退烧，病根还在。既然一份 Dump 不够，那就把四份一起摆上桌，请第二位专家ChatGPT来做个联合会诊。

ChatGPT：四份 Dump 串起证据链

这一回分析得慢得多。ChatGPT对着四个 Dump 文件来回翻了半个小时，总算把散落的线索串了起来，锁定了一个意想不到的嫌疑人：一直在后台默默写代码的Kimi。

原来，Kimi在后台写出的代码里藏着一颗“内存炸弹”：某次运行竟然试图申请超过 200 GB 的内存。系统资源被迅速吃光，最后倒下的却是显卡相关模块，于是 Dump 里的第一现场看起来就像显卡驱动闯了祸。

显卡驱动站在崩溃现场，一脸无辜：不是，怎么又算我头上？

Kimi：我建议先复现一下

既然嫌疑指向了Kimi写出的代码，那就轮到它自查了。

没想到，Kimi开口第一句话就差点让我从椅子上滑下去：

我们先复现一下问题。

复现？那可是一次申请 200 GB 内存的复现！这哪里是复现 Bug，这是要在现场再办一场黑屏发布会。

我赶紧叫停。在接受了一番严肃的安全教育之后，Kimi终于放弃了“再炸一次看看”的大胆想法，改为老老实实检查代码和编译结果。

经过一轮漫长分析，Kimi又找到了新的怀疑对象：Visual Studio 的 C/C++ 编译器cl。

按照Kimi的判断，代码本身似乎没有问题，开发阶段使用/O0编译时运行也正常；但验证场景切换到/O2后，编译器对栈内存进行了重排，导致内存申请相关变量的偏移出现异常，最终触发了那次离谱的超大内存申请。

最终，Kimi修改了代码，固定了关键变量的位置，绕开了编译优化带来的影响。重新编译、运行，一切恢复正常。

好了，这下终于可以安心地继续刷剧编程了。

番外：摸鱼篇

案子虽然破了，却还留下一个疑点：既然真凶不是显卡驱动，为什么升级驱动以后，电脑整整一个下午都安然无事？那段时间里，Kimi明明也一直在后台“努力工作”啊。

仔细一回想，我才记起来：下午出门前，我只给Kimi发了一条/init命令。等晚上回来一看，好家伙，六个多小时过去了，命令居然还没执行完，本该生成的AGENTS.md更是一个字都没有！

真相这才彻底水落石出：一下午没有蓝屏，新版驱动看起来很有功劳。其实电脑之所以安稳，只是因为真正的“真凶”这一下午压根没上班。

看来，比起甩锅，Kimi更擅长的还是摸鱼。

尾声

至此，这场由四次黑屏发起的“联合会诊”终于告一段落：Claude根据第一份现场报告先怀疑显卡驱动，ChatGPT对比四份 Dump 后发现资源耗尽的线索，Kimi再沿着自己的代码一路追到/O2优化下的异常行为。三位 AI 各自贡献了一段推理，也各自展示了一下什么叫“一本正经地把锅递给下一位”。

这次排障最有意思的地方，不是谁第一次就猜中了答案，而是每一步都让真相的范围更小了一点。Dump、调用栈、内存申请记录和不同编译参数下的表现，最终组成了一条比“看起来很像”更可靠的证据链。

所以，下次再遇到蓝屏，不妨先深呼吸，再打开 Dump。毕竟屏幕黑下去的时候，电脑通常不会主动交代；但它留下的线索，往往比任何一位信心满满的“专家”都诚实。

当然，前提是别让 AI 为了验证结论，再申请一次 200 GB 内存。

跳转微信打开