Баг Windows 11 в отдельных случаях раздувает системный файл до сотен гигабайт и незаметно отъедает место на SSD. Для IT-отделов, администраторов и тех, кто разворачивает рабочие образы Windows 11, история неприятная по простой причине: проблема сидит не в пользовательском мусоре, а внутри самой ОС.
О проблеме сообщает ZDNet: в Windows 11 может бесконтрольно расти файл CapabilityAccessManager.db-wal, связанный со службой Capability Access Manager Service. Она отвечает за разрешения приложений на доступ к камере, микрофону, геолокации и другим чувствительным функциям. Суффикс db-wal означает журнал предварительной записи: система сначала складывает изменения туда, а уже потом переносит их в основную базу. Сам по себе такой файл не выглядит подозрительно, но в норме его размер должен измеряться мегабайтами, а не сотнями гигабайт.
По данным источника, именно этот системный файл в поврежденном состоянии способен вырасти до 500 ГБ. ZDNet ссылается на публикацию Windows Latest и напоминает, что жалобы на аномальный рост появились как минимум год назад: один пользователь Reddit еще тогда сообщил о файле, занявшем гигантский объем. То есть речь не о вчерашнем сюрпризе после очередного «вторника патчей», а о затянувшемся дефекте, который просто не спешили признавать заметной проблемой. Пока диск не начинает внезапно заканчиваться, баг Windows 11 легко принять за обычную деградацию системы, особенно на машинах с длинным жизненным циклом и плотным набором корпоративного софта.
Проверка, впрочем, не требует ни реверс-инжиниринга, ни плясок с правами доступа. Первый индикатор можно увидеть прямо в настройках Windows: Параметры → Система → Хранилище → Показать больше категорий. Если раздел Система и зарезервировано укладывается в пару десятков гигабайт, паниковать рано. Если же он уходит далеко за 100 ГБ, это уже похоже не на норму, а на симптом. Автор ZDNet проверил несколько своих установок Windows 11, включая виртуальные машины. Почти везде этот раздел занимал от 5 до 25 ГБ, но на основном ноутбуке вырос до 151 ГБ. Для рабочей станции это уже не статистический шум, а прямой повод разбираться.
Сам файл лежит по пути C:ProgramDataMicrosoftWindowsCapabilityAccessManager, но по умолчанию Windows не дает просто так залезть в этот каталог. И это, пожалуй, тот редкий случай, когда не стоит сразу идти по пути «сейчас я себе все открою через ACL». Более безопасный вариант — посмотреть структуру диска утилитами вроде WizTree, TreeSize или WinDirStat, запущенными с правами администратора. Есть и штатный способ через Robocopy: команда robocopy "C:ProgramDataMicrosoftWindowsCapabilityAccessManager" "%TEMP%CAMCheck" /L /B /R:0 /W:0 /BYTES /NP позволяет быстро увидеть размеры файлов без лишнего творчества с системными разрешениями. На здоровых системах ZDNet увидел там около 57 тысяч байт. На проблемном ноутбуке тот же CapabilityAccessManager.db-wal весил уже 7 ГБ — еще не апокалипсис, но явно не штатное поведение.
Самое важное в этой истории — Microsoft уже выпустила исправление, хотя не в самом торжественном жанре. В опциональном preview-обновлении от 23 июня 2026 года появилась формулировка о том, что апдейт «улучшает использование дискового пространства для файла CapabilityAccessManager.db-wal». Формулировка, мягко говоря, дипломатичная: когда системный журнал может съесть сотни гигабайт, слово «улучшает» звучит почти как корпоративный стендап. Но по сути это и есть патч для проблемы. Тем, кто готов ставить предварительные накопительные обновления, достаточно зайти в Windows Update и установить июньский preview-пакет. Тем, кто живет по более консервативному циклу, ZDNet советует дождаться обязательного июльского обновления, запланированного на 14 июля 2026 года: туда это исправление должно войти уже для всех.
Для бизнеса и IT-команд здесь есть несколько практических выводов. Во-первых, баг Windows 11 бьет не только по свободному месту, но и по диагностике: переполненный диск на пользовательской машине обычно начинают лечить чисткой профиля, временных файлов, кэшей IDE, артефактов контейнеров или OneDrive, а не охотой за внутренним журналом системной службы. Во-вторых, проблема особенно неприятна на ноутбуках с SSD на 256 или 512 ГБ, которые до сих пор массово закупают для офисных и гибридных сотрудников. Если один системный файл внезапно занимает десятки или сотни гигабайт, машина начинает вести себя как «уставшая», хотя железо тут вообще ни при чем. В-третьих, это еще один аргумент в пользу регулярного мониторинга категорий хранилища и нетипичных файлов на эталонных образах, а не только на боевых инстансах после жалобы пользователя.
История с CapabilityAccessManager.db-wal хорошо показывает старую, но все еще живую особенность Windows: даже сравнительно локальный сбой в подсистеме разрешений может долго маскироваться под обычное засорение диска. Для Microsoft это мелкий дефект без фанфар, для корпоративной эксплуатации — еще одно напоминание, что состояние системного хранилища давно стало частью базовой гигиены, а не задачей «когда-нибудь потом, если у пользователя закончится место».