微软通过 2026 年 7 月安全更新修复了严重的存储占用问题 2026 年 7 月的补丁星期二更新已经发布,其中包含一项一些用户从 3 月起就一直在等待的存储修复。Windows 11 KB5101650 修复了 Capability Access Manager 的漏洞,这个漏洞会悄悄占满系统盘,而且由于它会在正常推送阶段发布,所以所有符合条件的电脑都会直接安装,无需等待渐进式推送。

Windows Latest 本月早些时候报道了这个漏洞如何吞掉高达 500GB 的存储空间。一个名为 CapabilityAccessManager.db-wal 的文件不断增长,直到 C: 盘空间耗尽,而 Windows 在设置中始终没有指出是哪一个文件造成的。

对于一个可能吞掉半个太字节的漏洞,微软的修复说明相当低调:
“[存储] 此更新改进了 CapabilityAccessManager.db-wal 文件的磁盘空间使用情况。”
这项修复最早出现在 6 月的可选更新 KB5095093 中,不过并不是在发布当天。微软在更新发布 6 天后的 6 月 29 日,才把这条存储说明补进了更新日志。

KB5101650 会带来 6 月预览版中的所有非安全更新,这意味着该修复适用于 Windows 11 25H2 的 Build 26200.8875 和 24H2 的 Build 26100.8875。这项存储修复会通过正常推送到你的电脑,也就是说所有符合条件的设备都会一次性收到,不像微软用于分批推出点时间还原或新 Widgets 行为等功能的渐进式推送。安装更新后,存储修复就会生效。


微软所说的“改进磁盘空间使用情况”,指的是今后的检查点流程。它并没有说明已经涨到 200GB 的 WAL 文件是否会自动缩小,而多位安装了 6 月预览版的用户报告称,更新后该文件仍然很大,只有在手动删除后才恢复正常。
可以把 7 月更新看作是阻止其继续增长的一步,然后自己检查文件,确认是否仍需要清理。
Capability Access Manager 作为一个名为 camsvc 的服务运行,每当应用请求摄像头、麦克风、位置或屏幕捕获时,它都会记录一次。这些事件会显示在 C:\ProgramData\Microsoft\Windows\CapabilityAccessManager\. 中的 SQLite 数据库里。

CapabilityAccessManager.db 是数据库本体。.db-wal 文件是它的预写日志,用来暂存尚未写回数据库的更改。Windows 本应定期对该日志进行检查点处理并将其缩小。在受影响的电脑上,这个检查点没有运行,于是日志不断累积写入,却从未清理。
IT 管理员 Max Allen 在他的 Azure to the Max 博客上追踪了大约 10,000 个终端上的这个漏洞,而他团队标记为高写入量的产品几乎都与地理定位有关。Rainmeter 的 WiFiStatus 插件是首个被记录的案例。2025 年 3 月,一名用户报告称,在 Windows 11 24H2 让该插件请求位置访问后,相关文件在不到 10 小时内就涨到了 30GB。Rainmeter 开发者 jsmorley 在该讨论串中确认,该插件每秒大约会查询数据库 10 次。
来源:Azure to the maxDell 的 SmartByte 网络工具,由 Rivet Networks 开发,也在后续报告中多次出现。在 Allen 的博客上,一位直接查询数据库的读者发现,清理文件后仅 30 分钟内,SmartByte Network Service 就导致了 9,355 次写入,相关的 RivetAPS 进程又增加了 923 次。另一条评论则把他们 91GB 的文件追溯到 GeoComply,这是一个用于受监管体育博彩网站的位置验证应用,并确认在卸载该应用后 WAL 停止增长。
不过,第三方软件其实并不是根本原因。Allen 团队在测试机上停止这些被标记的应用后,WAL 文件仍然拒绝自行合并回主数据库。用 DB Browser for SQLite 手动打开同样的文件时,它们会在没有任何错误的情况下合并,因此数据库本身一直是完好的。真正坏掉的是 camsvc 内部的检查点逻辑,而这些被标记的应用只是写入速度最快的那些。
Allen 所追踪的所有受影响机器都运行着 2026 年 3 月更新或更高版本,具体为 10.0.26200.8037、10.0.26200.8039 或 10.0.26200.8246。Windows Latest 认为,问题可能是由 2026 年 2 月或 3 月的更新引入的。
6 月 29 日并不是微软第一次承认这个问题。根据 Allen 的报道,微软支持团队曾在 2026 年 5 月 13 日就向他私下确认,这个漏洞属于已知问题,当时他已提交了一项支持案例;团队还表示,产品组正在开发永久修复,预计会在 6 月底或 7 月初完成。微软当时还提供了一个手动临时解决方案:通过 msconfig 启动安全模式,运行 net stop camsvc,然后直接删除 WAL 文件。
Windows 发布健康仪表板中并没有显示这一确认。Windows 11 25H2 的已知问题页面列出了 GIF 面板问题和回收站文件命名故障,二者都已解决,但没有任何条目提到会把存储盘塞满的漏洞。

在一周内跟踪的大约 10,000 台设备中,59% 的 WAL 文件超过 1GB,平均文件增长了 1.1GB,数百台增长超过 10GB,最严重的一台在那一周里增加了 65GB。有一台设备达到了 332GB。大约 200 台机器需要手动干预,Allen 还预计在 7 月 14 日更新到来之前,另有 300 台会耗尽空间。
相比之下,其他 IT 管理员对约 8,000 台设备的另一次扫描,仅发现一个文件超过 500MB。这个漏洞对某些环境打击很重,但对大多数机器几乎没有影响,这或许也解释了为什么它长期没有出现在公开仪表板上。
打开 设置 > 存储 > 显示更多类别 > 系统和保留,然后检查系统文件。如果数值达到数百 GB,而且没有休眠文件或过大的分页文件可以解释,那就是问题所在。Windows 在这个界面里不会标明是哪一个文件造成的。
由于漏洞,Windows 系统保留占用了 115GB若想在不需要权限的情况下确认,可在提升权限的命令提示符中运行以下命令。
robocopy “C:\ProgramData\Microsoft\Windows\CapabilityAccessManager” “%TEMP%\CAMCheck” /L /B /R:0 /W:0 /BYTES /NP
/L 只列出文件,/B 是备份模式,这样 Robocopy 就能读取受保护的系统文件而无需获取所有权,/R:0 和 /W:0 则会在访问被阻止时停止重试。不会复制任何内容。
健康的系统文件检查 CapabilityAccessManager.db-wal 旁边的字节数。正常系统上,它大约是 1.6MB。如果显示为数 GB,或者在 10 分钟后再次运行命令时继续增长,你的电脑就受到了影响。
WizTree、TreeSize 和 WinDirStat 也可以用,不过该文件夹被锁定给 SYSTEM 账户,所以普通管理员扫描通常只会把空间显示为未分配,而不会直接指向该文件。
要确认存储修复是否已应用到你的电脑,先安装 7 月更新。打补丁前先清空日志会让同样的循环重新开始,而且有一位在微软 Q&A 讨论串中的用户报告说,在漏洞首次出现时,手动重置后一天文件又涨回接近 1.8GB。
重启后再检查一次文件。如果它已经降到几百 KB,那就说明修复成功,不需要再做别的。

只有在安装 7 月更新后仍看不到任何变化时,才继续执行以下步骤:
如果它仍然巨大,微软在同一个 Q&A 讨论串中、修复发布前给出的建议是:在停止 camsvc 后进入安全模式,删除 CapabilityAccessManager.db-wal,并且不要动该文件夹中的其他任何文件,包括 CapabilityAccessManager.db 本身。该讨论串中的一位用户用这种方法恢复了 276.6GB 空间。
r/WindowsHelp 上的一位 Reddit 用户则选择了 Windows 恢复环境方案:他们没有删除,而是把一个 200GB 的文件重命名,让 Windows 自动生成一个新的日志文件,等确认新文件可用后再删除旧的重命名副本。
微软 Q&A 讨论串中的几位用户在这一步遇到了问题。在 camsvc 仍在运行时删除 WAL 文件,或者为了绕过“访问被拒绝”错误而手动取得文件夹所有权,结果导致有些人的 Wi-Fi 网络完全不显示、camsvc 启动失败并报错 1067,或者设置中的“位置”页面超时。
在这些情况下,使用 icacls “C:\ProgramData\Microsoft\Windows\CapabilityAccessManager” /reset /T /C 重置权限后,系统恢复了正常功能。还有少数用户丢失了已保存的 Wi-Fi 密码,不得不手动重新连接,然后重新授予之前已批准应用的摄像头和麦克风访问权限。
如果你的硬盘已经满了,Windows Update 也无法下载 KB5101650,那么先清理这个文件就是唯一可行的办法。其他人都应该先安装更新,之后检查文件大小,只有在数值没有下降时才选择删除。