用途与实际影响
这项功能怎样使用
为什么需要它
系统提交量耗尽可能来自某个应用、内核池或其他来源；一个进程此刻占用最多，不能证明它造成了之前的卡死。只扩大分页文件只能增加余量，持续保留故障前后的数字，才能区分真正增长的来源。
举个实际例子
“刚才电脑突然卡住，重开后又正常了。看看卡住前是谁的内存在涨，先别结束程序。”系统先对齐发生时间，读取上一会话留下的尾段、邻近内存记录和Windows事件，比较进程私有字节、系统提交量与内核池变化；日志缺失时说清缺口，不把当前排行榜当根因。
最后我会得到什么
给我故障前后能读到的内存变化、当时相关程序和仍缺的时段。它帮助缩小原因，不会自行结束程序；突然断电前尚未写下的最后一小段可能找不回来。
正常时
故障时段确有记录时，比较当时程序和整机内存的变化，只对证据支持的原因下结论。
发现问题时
日志损坏或某类内存突然增长时，说明具体疑点与接下来的检查，不靠重启掩盖。
入口不可用或证据不足时
没有当时记录或断电尾段丢失时直接说明，保留现有材料，不猜哪个程序造成卡顿。
从哪里开始
电脑卡住后，在已接入 PCConfig 的 AI 对话中提供发生时间，要求读取“内存卡顿诊断”；这是只读分析入口。
需要准备什么
- 卡顿或断电的大致时间
- 是否已重启
- 希望排查的程序线索
从开始到拿到结果
- 1
圈定故障时间
先把现象和重启时间对齐，避免拿现在的进程榜解释过去。
- 2
读当时记录
读取上一会话尾段、内存计数和 Windows 事件，比较进程与系统内存变化。
- 3
交回可能原因
列出有证据的增长线索和缺口；未保存的断电尾段不能补猜，也不会自动结束进程。
技术实现与依据
这里保留实现、关键条件、精确入口、历史记录和验证结果。
2026-09-14 02:55 UTC只读现场：原生收集器运行、自动接续启用、最近维护结果0；自然开机与硬断电尾部仍未验关键规则与设计选择
系统提交量、内核池和进程私有内存共同判断；最高占用不等于内存泄漏。
采样在Windows原生性能收集器中持续进行，短脚本只做开机接续和分段后的限额清理。
记录是有界故障证据，不是全机活动库；不读取命令行、窗口标题、聊天或文件正文。
PerfMon（性能监视器）停止当前记录；要重启后仍停用，使用Stop或同时禁用对应任务。
4,320段是数量上限，不是保证保留三天；硬断电可能损坏当前段或丢失未落盘尾部。
本模块用到的名词
- System commit（系统提交量）
- Windows已承诺提供后备存储的内存总量；应与提交上限和各来源趋势一起看。
- Kernel pool（内核池）
- 内核和驱动使用的内存，分别查看分页池与非分页池，不能全部归因给应用。
- BLG（Windows二进制性能日志）
- 保存计数器随时间变化的原生文件；文件存在不等于数值与故障时段可读。
专业定义
即使AI、数据库或网络不可用，Windows仍按固定间隔留下内存与进程证据；恢复后按故障时间查，而不是只看当前任务管理器。
解决什么
故障发生后现场容易消失；把记录放进依赖数据库、网络或AI的链条，还可能与业务一起停止。因此Windows原生收集器保留必要数字，AI在故障发生后才读取和判断，机器稳定配置与诊断时序保持分开。
当前怎样实现
- tools/Invoke-MemoryFreezeDiagnostics.ps1管理Install、Start、Stop、Status、Uninstall；唯一原生收集器为PCConfig-MemoryDiagnostics，根目录任务为PCConfig Memory Diagnostics。
- PLA（Windows性能日志与警报）每5秒记录Committed Bytes、Commit Limit、Available MBytes、Pool Paged/Nonpaged Bytes、Pages Output/sec、Page Reads/sec、Paging File使用率，以及Process实例的Private（私有） Bytes、Working Set、ID Process。
- 收集器将BLG（Windows二进制性能日志）写入E:\Data\Diagnostics\MemoryFreeze\rolling，每60秒或16MiB封存一段，递增序号避免覆盖同名旧段。
- 同一SYSTEM任务在开机延迟30秒和分段关闭时运行memory_freeze_maintenance.vbs；无额外轮询器，任务IgnoreNew（忽略重复实例）、限2分钟、失败最多重试3次，不要求用户登录。
- Windows原生DataManager（日志保留管理器）按最旧优先清理，rolling限1024MiB或4320段；当前段、清理过程与文件系统预分配允许少量暂时超额。
- 从停止状态启动前，previous-sessions另存上一会话最新15段、最多64MiB，只留最近三个会话；先保留尾段，再清理循环区。后续启动仍可能淘汰超过三份的旧会话。
- 维护错误写last-maintenance-error.txt，成功重试不覆盖它；该文件不存在仅表示未记录到维护错误。install-preimage.json保存最近安装前的任务/收集器配置，安装失败按前像恢复，独立于采样数据。
- perfmon.exe的“数据收集器集→用户定义”显示运行状态、间隔和位置；taskschd.msc显示任务启用、最近运行与开机触发。Stop先禁用维护任务，再停止本收集器；完成回调不会复活已停止收集器。
- 故障后优先读取previous-sessions与Windows System/Application/Resource-Exhaustion事件，再读rolling邻近关闭段；用relog导出指定计数器，核对数值、时间跨度和PID。Import-Counter曾对有效文件报错，不能据此认定日志已坏。
- Get-ComputerStutterDiagnostic.ps1将TimeAudit有界摘要、原生内存黑匣子和Windows事件按同一时间窗交回，保留每条来源的覆盖和未知。TimeAudit当前心跳、原生BLG存在与故障根因不能互证；只读取故障判断所需范围，不重启或结束业务程序。
执行流程
- 1
记录异常及断电时刻并统一到UTC
- 2
只读Status确认采样状态与保存位置
- 3
选上一会话尾段和故障邻近已关闭BLG
- 4
用relog读取必要计数器并结合Windows事件
- 5
按当时PID比较私有内存、系统提交与内核池趋势
- 6
交回原因排序、覆盖缺口与有依据的下一步
边界
- 不依赖Codex、TimeAudit、Docker或网络，不读取私人正文。
- 不杀进程、不重启电脑、不重置显示；记录不会自动修复内存泄漏。
- 硬断电的活跃段和未落盘尾部可能损坏或丢失；不承诺保住最后一秒。
- 停止与卸载保留日志；日志清理由具体诊断和已有保留策略负责。
- PID与时间共同归因，进程实例后缀可能复用。
- 本轮没有读取用户采样数字、运行relog或进行启停/断电演练。
失败与恢复
- 原生安装或配置回读失败
- 按install-preimage恢复原任务和收集器；回滚失败单独报告，不把部分安装当可用。
- 收集器手动停止后收到分段完成事件
- 回调保持停止；只有明确Start或仍启用的下一次开机任务才接续。
- 维护失败或任务结果非零
- 保留最近错误与实际状态，先诊断阶段和代码；无错误文件不能反推没有丢样。
- 非分页池突增而应用占用不解释系统提交
- 转向内核池与驱动取证，不能把当前进程排行当成原因。
- 硬断电后最后日志不可读
- 使用已关闭分段和保存的会话尾段，明确缺失范围，不补成正常或根因已找到。
真实入口
E:\PCConfig\docs\recovery\memory-freeze-diagnostics.md用途、数据类别、原生GUI、停止语义、限额、断电边界和恢复流程
E:\PCConfig\tools\Invoke-MemoryFreezeDiagnostics.ps1配置、安装回滚、Status和独立启停入口
E:\PCConfig\tools\memory_freeze_maintenance.vbs一次性事件维护、旧会话尾段保留、限额和最后失败
如何验证
- 2026-09-14 02:55 UTC只读Status返回installed=true、collector_state=running、automatic_start_enabled=true、last_maintenance_result=0、last_maintenance_error=null。
- 同次现场回读采样5秒、分段60秒、1024MiB和4320段，与源码定义一致；当前日志路径存在于状态输出，但本轮没有读取计数器数值。
- 源码与运行状态、关闭段可读、停止不复活、新Start保留尾段、真实开机和硬断电尾部是不同证据。本轮未新验后五项，不把running或任务结果0当成全部通过。
与其他模块的关系
机器事实模块拥有稳定硬件与配置投影；本模块拥有内存故障时序、采样生命周期及故障后读回。TimeAudit提供更广历史信号，Windows轨迹分析器处理明确选定的ETL；它们不替代本模块独立的原生BLG记录，也不形成第二个监控项目。