微软终于承认：Win11有个Bug能悄悄吞掉你500G硬盘，赶紧看看你中招没

麻薯滑芝士

嘿，那些最近发现自己C盘空间莫名其妙少了一大截、打开Steam发现游戏因为硬盘不够都更新不了的玩家，还有那些每天上班打开电脑就看到“磁盘空间不足”弹窗、但又死活找不到到底什么东西占了地方的办公族，再加上那些喜欢折腾系统、动不动就打开任务管理器看资源占用、结果发现“系统与保留”那一项飙到上百G直接懵圈的技术控，甚至连那些平时根本不关心硬盘空间、只是某天想存个文件却发现存不进去了、然后才开始到处翻到底是哪个文件夹在搞鬼的普通用户——今天这条消息，你们每一个人都得瞪大眼睛看好了，因为微软终于亲口承认了，他们家的Win11系统里藏着一个能把你的硬盘空间占用到几乎爆满的Bug，而且这个Bug已经在你们眼皮子底下“潜伏”了快有半年了。

这事儿说来真的挺让人窝火的。你想想，你正常用着电脑，没下什么3A大作，没囤什么蓝光原盘电影，甚至连微信聊天记录都定期清理，结果某一天系统突然弹个窗口告诉你“C盘空间不足”，你打开存储设置一看，“系统与保留”那一栏赫然写着八九十个G甚至一百多个G。你当时心里肯定在想：我特么系统才装多久啊，这些系统文件是吃了生长激素吗？然后你开始满世界排查，用各种磁盘分析工具扫了一遍又一遍，看到的都是些零零碎碎的小文件，没有一个能对上那个巨大的空间缺口。你甚至怀疑自己是不是中了什么挖矿病毒，但查了一圈也没发现任何异常。这种感觉就像是你钱包里的钱莫名其妙少了一半，但你翻遍了所有口袋和抽屉，就是找不到任何消费记录，整个人又烦躁又无力。

现在好了，专门跟踪Windows动态的科技媒体Windows Latest在前段时间发了一篇非常详细的调查报道，算是把这个困扰了无数用户好几个月的谜团给彻底解开了。问题的根源，藏在Windows 11系统深处一个绝大多数人压根没听说过的地方。这个罪魁祸首的名字叫 CapabilityAccessManager.db-wal​ ，它是一个跟系统权限管理有关的数据库文件。在正常情况下，这玩意儿体积小得可怜，大概也就一到两兆字节的样子，放在你那个动不动就几百G甚至上T的硬盘里，简直就像大海里的一粒沙子，根本不会引起任何人的注意。但问题就在于，当这个Bug被触发之后，这粒沙子会像吃了酵母一样疯狂膨胀，变成一块巨石——几十个G、两百个G，甚至五百个G。你没看错，五百个G。这意味着你电脑里那块用来装操作系统和各种软件的固态硬盘，可能有将近一半甚至更多的容量，都被这一个不起眼的文件给独吞了，而你从头到尾对此一无所知。

那这个CapabilityAccessManager到底是个什么玩意儿呢？我来给你掰扯清楚。它的全称叫Capability Access Manager，中文可以理解为“功能访问管理器”，是Windows 11系统里一套跟应用权限紧密相关的后台机制。你平时用电脑的时候，但凡涉及到麦克风、摄像头、定位信息、屏幕截图这些跟个人隐私沾边的敏感功能，系统都会通过这个管理器来详细记录到底是哪一个应用程序在什么时间点调用了哪一项权限。你可以把它想象成一个特别较真的门卫大爷，手里拿着一个小本本，每一个进出大楼的人他都要登记：张三几点几分进了大门，李四几点几分去了三楼，王五几点几分碰了消防栓——事无巨细，全给你记下来。从设计初衷来说，这套机制是有它的价值的，毕竟谁也不希望自己的摄像头被某个不知名的流氓软件在深更半夜悄悄打开对吧？有了这套日志系统，起码你能回头查查到底是谁在背后搞小动作。

但这个门卫大爷的小本本，它的记录方式出了一点岔子。CapabilityAccessManager的背后实际上是一个SQLite数据库，而那个“.db-wal”后缀的文件，是这个数据库的“预写日志”，英文术语叫Write-Ahead Log，简称WAL。这个机制的原理大致是这样的：数据库在正式把数据写进主文件之前，会先把所有的操作临时记录在这个WAL文件里，相当于先打个草稿，等积累到一定量之后再统一合并回主文件里去。这个过程在正常情况下是自动完成且非常高效的，就像你写完一篇作文的草稿之后，把它工工整整地誊抄到正式作业本上，然后把草稿纸扔掉。但不知道从哪个版本开始，Windows 11的这个“誊抄”流程出了故障——系统一直在往这个草稿本上刷刷刷地写东西，但写到后面就再也不管了，既不合并也不清理，任由这个草稿本变得越来越厚。于是这个草稿本就从几页纸变成了一本书，又从一本书变成了一套百科全书，最后直接堆成了一座小山。

Windows Latest在他们的实际测试中清楚地展示了正常状态和异常状态之间的巨大差距。在他们的一台没有受影响的电脑上，整个CapabilityAccessManager文件夹加起来的体积还不到4MB，而那个.db-wal文件更是只有大约1.6MB。这才是一个健康的、正常运行的系统应该呈现的状态。但是，根据大量来自真实用户的反馈以及Windows Latest自己的复现测试，这个文件在某些机器上能够膨胀到一个完全失控的程度。有一位用户在微软官方的Feedback Hub——也就是那个专门收集用户意见和Bug报告的平台上留言说，自己电脑里的CapabilityAccessManager.db-wal文件已经长到了差不多200GB。这还不是最夸张的。Windows Latest的编辑在Reddit的r/techsupport板块里发现了一个讨论帖，里面的楼主上传了一张用TreeSize扫描的结果截图，显示同一个文件占用了大约513GB的空间。什么概念呢？同一台电脑上，系统虚拟内存文件pagefile.sys和休眠文件hiberfil.sys这两个出了名的硬盘大户，加在一起也才29GB左右。一个日志文件比两个系统核心文件加起来大十几倍，这种事情说出来你敢信？在那个帖子的评论区里，其他用户也纷纷报上了自己的遭遇：70GB的、110GB的、200GB的，什么样的都有。还有些人说自己在手动清理之后，这个文件暂时缩回到了4GB或者15GB的水平，但只要正常用几天，它又会悄悄地涨回去。

那么这个Bug到底是从什么时候开始出现的呢？根据Windows Latest的调查，最早在今年年初——也就是2026年的头几个月——就已经有普通用户在网络上反映这个现象了。而在过去的几个月里，参加了Windows Insider预览计划的那些测试用户，也多次通过内部渠道向微软反馈过这个异常情况。但微软那边的反应，怎么说呢，慢得让人着急。他们既没有公开承认这是一个已知的系统缺陷，也没有在官方的Windows健康仪表板上列出任何相关的警告信息，更没有向用户解释这个文件为什么会疯长、长了之后会造成什么后果。就这么一直拖着，拖到了2026年6月29日，也就是大概一个星期多以前，微软才终于在每个月例行的可选更新里，悄悄地塞进了一个针对这个问题的修复补丁。这个补丁的编号是 KB5095093​ ，属于2026年6月的可选更新。在它的发布说明里，微软只用了一句话来描述这个改动，原文是：“此更新改进了CapabilityAccessManager.db-wal文件的磁盘空间使用情况。”就这一句话，没了。没有解释这个Bug到底有多严重，没有告诉用户这个文件最多能吃进去500个G的空间，没有说明为什么会出现这个问题，也没有提供任何帮助用户判断自己是否中招的指引。就这么轻飘飘的一句，好像这只是一个无伤大雅的小优化似的。

更让人觉得离谱的是，直到Windows Latest这篇报道发布的那个时候，微软的官方已知问题页面里，依然没有任何一条关于这个Bug的公开说明。也就是说，如果你不是一个天天泡在科技新闻里的人，如果你没有恰好读到Windows Latest的这篇报道，你根本不可能知道自己的电脑到底出了什么毛病。你只会看到“系统与保留”那一栏的数字高得吓人，但你完全无从知晓究竟是哪个具体的文件在作祟。Windows的存储设置界面只会笼统地告诉你“系统文件”占了多少多少空间，但它永远不会告诉你具体是哪些文件。这种信息上的不透明，说实话，对于一个拥有十几亿用户的操作系统来说，是非常不负责任的。

那如果你现在开始担心自己的电脑可能也中招了，该怎么确认呢？Windows Latest在这篇文章里给出了两种不同的检测方法。第一种比较直接，就是用第三方的磁盘分析工具来扫描。市面上有几款口碑不错的免费工具可以用，比如WizTree、TreeSize还有WinDirStat。你需要以管理员身份运行这些工具，然后在扫描结果里按文件体积从大到小排序，直接去找那个名叫CapabilityAccessManager.db-wal的文件。如果它的大小只有几兆字节，那恭喜你，你的电脑是安全的。但如果它显示的是几十个GB甚至上百个GB，那你就是不幸中招的用户之一了。

第二种方法更稳妥一些，不需要你去修改任何系统权限，也不会对你的系统造成额外的风险。你只需要以管理员身份打开命令提示符——就是在开始菜单里搜cmd然后右键选择“以管理员身份运行”——然后输入下面这一整行命令：robocopy "C:\ProgramData\Microsoft\Windows\CapabilityAccessManager" "%TEMP%\CAMCheck" /L /B /R:0 /W:0 /BYTES /NP

这行命令看起来有点长有点唬人对吧？没关系，我给你把这串东西拆开来一个一个讲清楚，保证你听完之后心里明明白白的。Robocopy是Windows系统自带的一个非常强大的文件和目录复制工具，全称是Robust File Copy。这里面每一个斜杠开头的参数都有自己的作用：/L这个参数的意思是“仅列出”，也就是说它不会真的去复制任何文件，只是把源文件夹里的文件信息列出来给你看一眼；/B参数是备份模式，它允许Robocopy绕过文件系统的权限限制，直接读取那些受系统保护的文件，而且在这个过程中不会修改任何权限设置；/R:0表示如果某个文件因为权限或其他原因无法访问，不要进行重试；/W:0则表示在两次尝试之间不要有任何等待时间；/BYTES是以字节为单位来显示每个文件的具体大小；/NP是关闭复制进度显示的选项，因为反正我们也不需要真的复制什么东西。至于命令后半部分的"%TEMP%\CAMCheck"，那是一个临时的虚拟目标文件夹路径，但因为前面有/L参数的存在，实际上不会有任何文件被复制到那里去。整条命令执行完毕之后，你会在命令提示符的输出结果里清清楚楚地看到CapabilityAccessManager.db-wal这个文件的大小。如果它只有几MB，那你就可以放心了。但如果它显示的是几十个GB甚至更多，而且你发现每隔几分钟重新运行一次命令之后，这个数字还在持续增长，那你的电脑毫无疑问是被这个Bug影响了。

那如果真的确认中招了，该怎么办呢？微软提供的官方解决方案目前有两个办法。第一个办法是立即安装那个修复补丁，也就是Windows 11的KB5095093更新。需要注意的是，这个更新目前属于可选更新，不会自动推送到你的电脑上，你需要手动进入Windows更新设置界面，点击“检查更新”，然后在可选更新列表里找到它并手动安装。第二个办法是等，等到2026年7月的“补丁星期二”那一天，同样的修复程序会被包含在月度安全更新里，自动推送给所有Windows 11用户。如果你的硬盘空间目前还算宽裕，不至于影响到正常使用，那你可以选择再等一等。但如果你发现C盘已经快被塞满了，连Windows更新都没办法正常下载和安装了，那你就得采取一些更直接的手段了。Windows Latest给出的应急处理方法是：从Windows恢复环境或者安全模式启动你的电脑，然后在那个受限的环境下，把那个体积异常庞大的CapabilityAccessManager.db-wal文件重命名——比如说改成CapabilityAccessManager.db-wal.old——这样Windows在下次启动时就会发现原来的日志文件不见了，它会自动创建一个全新的、干干净净的WAL文件。但这里有一个非常非常重要的提醒：千万不要在你正常登录的Windows系统里直接动手删除或者改名这个文件。因为系统文件之间存在着复杂的依赖关系，在系统活跃运行的状态下随便改动底层文件，可能会导致不可预料的后果，比如某些应用打不开、权限设置紊乱，甚至系统崩溃蓝屏。

说到这里，可能有些细心的人会问：为什么同一个Bug在不同的人电脑上表现出来的严重程度差别这么大？有的人只损失了几个G，有的人却被吞掉了五百个G？Windows Latest在文章里给出了他们的分析结论。他们认为，这个问题的根源很可能跟微软在2026年2月或者3月推送的某一个Windows 11更新有关。那个更新可能在底层改动了一些跟权限日志处理有关的代码逻辑，导致在某些特定的条件下——比如某些应用程序频繁地调用麦克风、摄像头、定位或者屏幕捕获功能时——系统会触发异常密集的日志写入操作。换句话说，你平时使用的应用程序越多、越杂，特别是那些动不动就要申请各种隐私权限的软件，你的电脑受到这个Bug影响的概率就越大、程度就越严重。这也就很好地解释了为什么有的人电脑上这个文件只有几MB而有的人却能冲到几百个GB——因为每个人的软件使用习惯和频率是完全不一样的。

最后我想说的是，微软这次对这个Bug的处理方式，说实话，真的不太地道。一个能够把用户硬盘吃掉五百个GB的重大缺陷，愣是被他们用一个含糊其辞的“改进磁盘空间使用”给一笔带过了。没有公开道歉，没有详细的技术解释，没有在已知问题列表里明确标注，甚至连一条像样的公告都没有发。要不是Windows Latest这帮科技记者刨根问底地把这件事情挖了出来并且持续跟进报道，恐怕到现在还有成千上万的用户面对着自己那个莫名其妙不断膨胀的“系统与保留”数值干瞪眼，完全不知道问题出在哪里。所以，如果你正在使用Windows 11，不管你觉得自己会不会中招，我都建议你现在就去检查一下你的存储设置。别等了，就现在，花两分钟时间看一眼，总比某天突然发现硬盘爆满要好得多。

bass

游客请登录后查看回复内容

行了吧

游客请登录后查看回复内容

zaybxc

游客请登录后查看回复内容