明天就是微软周二补丁日，修复 C 盘 BUG 的官方补丁就要全量推送了。
C 盘爆红的朋友，先别急着盲目更新。
最近很多人提前装了可选补丁，结果没两天日志又涨了十几 G。
清理完反弹、打完补丁还涨，折腾半天根本没根治，白白浪费时间。
我店里一上午就接了四台电脑，全是操作顺序错了。
建议先收藏起来，明天更补丁的时候照着操作，避免白忙活一场。
今天教你正确根治步骤，小白照着做也不会反弹。
正确根治两步走，一次解决不反弹 第一步：先彻底清理旧日志文件
这一步是根治的前提，90% 反弹的人都没做对。
操作：
- 按住 Shift 点重启，依次选择疑难解答→高级选项→启动设置→重启，按 4 进入安全模式
- 打开路径 C:\ProgramData\Microsoft\Windows\CapabilityAccessManager
- 只删除 CapabilityAccessManager.db-wal 文件，同名.db 主文件不要碰
重启后系统会生成一个几 MB 的新日志文件，几十 G 空间瞬间释放。
接下来第二步才是彻底修复的关键，别做完第一步就退出去了。
第二步：安装修复补丁
清理干净后再打补丁，才能真正从根源修复。
有两种方式按需选择：
- 小白等自动推送：明天 7 月 14 日微软会全量推送，打开设置→Windows 更新，点检查更新自动安装即可
- 着急就手动更：现在就能装 KB5095093 可选更新，设置→Windows 更新→高级选项→可选更新里勾选安装
避坑提醒：两个常见坑别踩
- 别先打补丁再删日志，等于白忙活一半，旧文件还占着空间
- 别用第三方清理工具扫系统文件夹，很容易误删主文件搞崩系统
补丁打完，怎么验证真的修好了？
很多人打完补丁就不管了，过几天又满了才发现没修好。
教大家一个简单的验证方法。
安装补丁重启后，去刚才的日志文件夹看一眼：
- 正常修复：db-wal 文件稳定在几 MB，用三五天体积也不会明显上涨
- 没修复成功：文件每天涨几百 MB 甚至几 G，说明补丁没生效，建议重启后重新检查更新
补充两个实用细节：
- 24H2 版本反弹概率最高，25H2 相对轻微，版本越旧越要按完整步骤来
- 建议 14 号下午再更新，上午刚推送时服务器不稳定，容易安装失败
- 临时没空操作的朋友，可以先把自动更新暂停 2 天，等补丁稳定了再处理
先给大家说清楚原因，避免后续再踩坑。
这次的 BUG 是日志文件只写不删、无限膨胀。
补丁只负责修复后续的写入逻辑，已经膨胀的旧日志不会自动清理。
如果日志文件已经几十 G，打完补丁它还在那儿占着空间，甚至会继续缓慢增长，看起来就像反弹了。
还有一种情况是没进安全模式删除，正常模式下文件被系统占用，表面删了实际没删干净，重启后又恢复原样。
反弹了怎么办？二次处理方法
如果已经打完补丁还在缓慢增长，也不用慌。
先重复一遍安全模式删日志的操作，然后去更新历史里确认 KB5095093 是否安装成功。
如果显示已安装仍反弹，就先卸载该补丁，重启后重新安装一次，大概率就能解决。
极少数情况是系统版本不兼容，这种可以等 14 号的全量正式补丁，稳定性比可选更新更好。
今天上午有个客户过来，24H2 版本的轻薄本，提前更了可选补丁，3 天涨了 18G。
他以为补丁没用，其实是没先清旧日志，重新操作完现在稳定在 2MB 左右。
说说我的真实看法
站在装机从业者的角度，我觉得这事微软做得确实不够厚道。
一个日志文件能膨胀到几百 G，明显是测试环节严重缺位，把用户当免费测试员。
更离谱的是，修复补丁藏在可选更新里，不主动找根本发现不了，多少人 C 盘红到爆还蒙在鼓里。
更讽刺的是，BUG 是微软自己搞出来的，擦屁股的活儿却全丢给用户自己研究。
连个官方清理工具、官方教程都没有，用户还要承担误操作的风险。
要是真重视用户体验，就该在发现 BUG 的第一时间推送应急清理工具，而不是让用户自己摸黑折腾。
觉得有用可以收藏转发给身边 C 盘爆红的朋友，省得他们踩坑走弯路。
最后聊聊
- 你的 C 盘现在还剩多少空间？有没有碰到清理后反弹的情况？
- 已经中招的扣 1，还没遇到的扣 2
- 你觉得微软该为这个 BUG 出官方清理工具吗？我觉得这本来就是它该承担的责任
注：本文部分公开数据与素材由 AI 辅助整理，全文结构、实操判断与行业观点均为人工原创输出，内容已人工审核校验
热门跟贴