蓝屏与内存检查：证据怎样分层

这次蓝屏排查没有找到一个可以直接盖章的“坏部件”。真正得到的进展，是把停止码、可用转储、内存测试和温度读数拆开核对，避免让一张截图或一次短测承担超过它能力的结论。

本文依据截至 2026 年 10 月 14 日的记录整理，整体背景见排查总览。

停止码是线索，转储决定能分析多细

10 月 13 日有两份可用的新转储：一次为 0x4E，第一参数为 6，另一次为 0x7E，伴随访问违规。两次均在新启动后的约 20 秒内发生，检测位置涉及不同的内存管理路径。

对于 0x4E/6，微软列出的机制包括页表结构损坏、硬件位错误或 DMA 传输异常。因此，它支持继续查内存相关路径，却不足以单独定位某根内存。某个桌面进程或虚拟 Wi-Fi 模块出现在当时的上下文、调用链中，也不能直接当作致因。微软：0x4E PFN_LIST_CORRUPT

10 月 14 日，使用者又看到 0x1A 和 0x139，但那轮没有保存到可用于深入分析的新转储，并有转储创建或初始化失败的记录。这里应写成“看到了停止码，细节证据不足”，不能把旧转储的调用栈套到新故障上。

0x1A 表示严重的内存管理错误，第一参数区分具体违规；0x139 表示内核检测到关键数据结构损坏，其中也可能涉及驱动错误。代码名称中出现“内存”或“安全检查”，均不自动证明内存条损坏或电脑中毒。微软：0x1A、微软：0x139

10 月 12 日，DISM 与 SFC 修复后又分别复查，结果支持当时组件库和受保护系统文件的完整性恢复。次日的新蓝屏并没有推翻这项结果，而是说明“磁盘上的系统文件正确”和“运行中的整机稳定”属于不同问题。

同样，文件数字签名有效、系统盘检查暂未发现介质错误，只能支持相应检查范围内的判断。它们不能替所有驱动代码、内存状态、供电或睡眠恢复行为背书。

重新核对旧测试照片后，确认它记录的是 Test 8 的 3 次数据不一致，发生在第一轮尚未完成时。这不是只有并行测试卡死，也不是把另一种测试的提示误计为错误。

这使硬件/平台稳定性检查具有较高优先级，但仍不能写成“某根内存已坏”。MemTest86 官方说明，测试也会涉及 CPU、缓存与主板；不同配置和条件下的结果可能不一致。PassMark：MemTest86 错误排查

照片中的旧温度字段没有得到充分交叉验证，公开结论不把它们当作真实 DRAM 温度，更不据此推导损坏程度。

10 月 14 日的记录中，同时存在以下结果：

结果类型	这次的例子	应该怎样记
实际数据错误	旧 MemTest86 的 3 次数据不一致	是需要继续查明的异常证据
温度保护中断	OCCT 日志为 `ScheduleOverheat`，同时写着 `No errors detected`	中断前没检测到计算错误；计划未完成，不能算通过
完整短测零错误	使用者确认后续一次装回屏蔽罩和底盖后，完整运行约 5 分钟，状态为 `ScheduleCompleted` 且无错误	支持这次条件下的短测结果，不等于覆盖全部内存或长期稳定

早期一次计划 3 分钟的测试，约 1 分钟就触发保护，CPU 相关温度已很高。后续也出现过只运行几秒即停止的轮次。它们与后来完整 5 分钟零错误并不矛盾：起始温度、负载、风扇、后台任务和测试参数可能不同，现有记录不足以量化每项影响。

另一轮开盖测试完成、零错误，以及装回部分结构后的温度，部分来自当时使用者的确认；它们没有全部配套同规格连续采样，不能据此精确计算“拆掉某部件降温了多少”，更不能认定曾经漏装部件。

这台机器可以读到两条 DDR5 的 SPD Hub 温度。SPD Hub 是模组上的管理芯片，其温度并不直接等于所有 DRAM 颗粒的温度；HWiNFO 作者也明确解释过这个区别。HWiNFO 作者关于 DDR5 温度传感器的说明

因此，CPU Package、PCH、SPD Hub 和软件汇总的“Memory”不能混为一个测点。某轮温度保护监控的是 CPU/GPU，也不能看到一个内存相关读数就认定它触发了保护。记录应同时保留传感器全名、当前值/最大值、采样区间及保护条件。

合理的下一步是带着简明时间线、新转储和内存测试结果，让售后在默认参数下做已知良好内存、插槽与平台的交叉检查，并覆盖冷启动和睡眠恢复。已有异常或保护中断时，继续堆叠高温压力测试并不能自动增加有效信息。

暂时避免易触发故障的睡眠场景、保存工作后正常关机，属于当时的缓解办法。它不构成修复证明；“五分钟没报错”也仍然只是一次有范围的观察。