Вышло июльское обновление Patch Tuesday 2026 года, и в нём скрывается исправление проблемы с хранилищем, которого некоторые пользователи ждали с марта. Windows 11 KB5101650 исправляет ошибку Capability Access Manager, которая незаметно забивала системные диски. Поскольку обновление распространяется в обычном режиме, оно устанавливается на все подходящие ПК без необходимости ждать поэтапного развёртывания.
Ранее в этом месяце мы рассказывали, как ошибка съедала до 500 ГБ хранилища. Один файл, CapabilityAccessManager.db-wal, продолжал расти, пока диск C: не заканчивался, и Windows нигде в настройках не указывала, какой именно файл виноват.
Для ошибки, способной проглотить полтерабайта, описание исправления от Microsoft выглядит довольно скромно:
«[Хранилище] Это обновление улучшает использование дискового пространства для файла CapabilityAccessManager.db-wal.»
Что изменилось для CapabilityAccessManager.db-wal в июльском обновлении
Исправление впервые появилось в июньском необязательном обновлении KB5095093, хотя и не в день его выпуска. Microsoft добавила строку о хранилище в список изменений 29 июня, через шесть дней после выхода обновления.
KB5101650 переносит все не связанные с безопасностью изменения из июньской предварительной версии, что означает исправление на сборке 26200.8875 для Windows 11 25H2 и сборке 26100.8875 для 24H2. Исправление хранилища доставляется на ПК в обычном развёртывании, то есть все подходящие устройства получают его сразу, в отличие от поэтапного развёртывания, которое Microsoft использует для таких функций, как восстановление на момент времени или новое поведение виджетов. Установите обновление, и исправление хранилища активно.
Формулировка Microsoft «улучшает использование дискового пространства» описывает процесс контрольной точки в дальнейшем. В ней не говорится, будет ли WAL-файл, уже разросшийся до 200 ГБ, автоматически сжат. Несколько пользователей, установивших июньскую предварительную версию, сообщили, что их файл оставался большим сразу после обновления и возвращался к норме только после ручного удаления.
Рассматривайте июльское обновление как шаг, который останавливает дальнейший рост, а затем проверьте файл самостоятельно, чтобы убедиться, требуется ли ещё очистка.
Почему CapabilityAccessManager.db-wal разрастался до сотен гигабайт
Capability Access Manager работает как служба с именем camsvc и регистрирует каждый случай, когда приложение запрашивает доступ к камере, микрофону, местоположению или захвату экрана. Эти события сохраняются в базе данных SQLite по пути C:\ProgramData\Microsoft\Windows\CapabilityAccessManager*.*
CapabilityAccessManager.db служит базой данных. Файл .db-wal является журналом упреждающей записи (write-ahead log), промежуточной областью для изменений, которые ещё не были внесены обратно в базу. Windows должна периодически создавать контрольные точки этого журнала и уменьшать его. На затронутых ПК эта контрольная точка не выполнялась, поэтому журнал продолжал накапливать записи без очистки.
Приложения с интенсивным использованием геолокации продолжали инициировать запись, но сбой был в Windows
ИТ-администратор Max Allen отследил ошибку примерно на 10 000 устройствах в своём блоге Azure to the Max. Все продукты, которые его команда отметила как активно записывающие, были связаны с геолокацией. Первым задокументированным случаем стал плагин WiFiStatus для Rainmeter, о котором в марте 2025 года сообщил пользователь, чей файл достиг 30 ГБ менее чем за 10 часов после того, как Windows 11 24H2 заставила плагин запрашивать доступ к местоположению. Разработчик Rainmeter jsmorley подтвердил в той ветке, что плагин опрашивал базу данных примерно 10 раз в секунду.
Сетевая утилита Dell SmartByte, созданная Rivet Networks, также неоднократно всплывала в более поздних отчётах. В блоге Аллена один из читателей, напрямую запросивший базу данных, обнаружил, что служба SmartByte Network Service была ответственна за 9 355 записей всего за 30 минут после очистки файла, а связанный процесс RivetAPS добавил ещё 923. Другой комментатор связал свой файл размером 91 ГБ с GeoComply, приложением для проверки местоположения, используемым регулируемыми сайтами спортивных ставок, и подтвердил, что WAL перестал расти после удаления приложения.
Однако стороннее ПО на самом деле не виновато. Когда команда Аллена останавливала отмеченные приложения на тестовых машинах, WAL-файл по-прежнему отказывался самостоятельно объединяться с основной базой данных. Открытие тех же файлов вручную в DB Browser for SQLite выполняло слияние без ошибок, так что сама база данных оставалась неповреждённой. Сбой был в логике контрольных точек внутри camsvc, а отмеченные приложения просто писали в него быстрее всех.
Все затронутые машины в парке Аллена работали под управлением мартовского обновления 2026 года или более позднего, в частности сборок 10.0.26200.8037, 10.0.26200.8039 или 10.0.26200.8246.
Microsoft подтвердила ошибку внутри компании в мае, за несколько недель до публичной записи в списке изменений
29 июня — не первый раз, когда Microsoft признала это. Согласно отчёту Аллена, служба поддержки Microsoft в частном порядке подтвердила ошибку как известную проблему 13 мая 2026 года в ответ на открытое им обращение и сообщила, что продуктовая команда работает над постоянным исправлением, ожидаемым примерно в конце июня или начале июля. Тогда же Microsoft предоставила ручной обходной путь: загрузка в безопасном режиме через msconfig, выполнение net stop camsvc и непосредственное удаление WAL-файла.
Панель работоспособности выпусков Windows нигде не показывает этого подтверждения. Страница известных проблем для Windows 11 25H2 перечисляет проблему с панелью GIF и глюк с именованием файлов в корзине, оба уже решены, но там нет записи, описывающей ошибку, способную заполнить диск.
Среди примерно 10 000 устройств, отслеживаемых в течение одной недели, 59% имели WAL-файл размером более 1 ГБ. Средний файл увеличился на 1,1 ГБ, несколько сотен выросли более чем на 10 ГБ, а на худшей машине добавилось 65 ГБ за эту неделю. Одно устройство достигло 332 ГБ. Около 200 машин потребовали ручного вмешательства, и Аллен прогнозировал, что ещё 300 исчерпают место до выхода обновления 14 июля.
Для сравнения, отдельное сканирование примерно 8 000 устройств, проведённое другими ИТ-администраторами, выявило ровно один файл размером более 500 МБ. Ошибка сильно ударила по некоторым средам, оставив большинство машин нетронутыми, что, вероятно, объясняет, почему она так долго не появлялась на публичной панели.
Как проверить, затронут ли ваш ПК
Откройте Параметры > Система > Память > Показать больше категорий > Система и зарезервировано и проверьте системные файлы. Цифра в сотни гигабайт, не объяснимая файлом гибернации или чрезмерно большим файлом подкачки, указывает на проблему. Windows нигде на этом экране не называет ответственный файл.
Чтобы подтвердить без дополнительных разрешений, выполните следующую команду в командной строке с правами администратора.
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,6 МБ. Если отображается несколько гигабайт или размер растёт при повторном запуске команды через десять минут, ваш ПК затронут.
Утилиты WizTree, TreeSize и WinDirStat также работают, но папка заблокирована для учётной записи SYSTEM, поэтому обычное сканирование от имени администратора обычно показывает пространство как неучтённое, а не указывает на файл.
Как освободить место после установки KB5101650
Чтобы убедиться, что исправление хранилища применилось к ПК, сначала установите июльское обновление. Очистка журнала до установки патча возобновляет тот же цикл, и один пользователь в ветке Microsoft Q&A (когда ошибка только проявилась) сообщил, что после ручного сброса файл снова вырос почти до 1,8 ГБ за день.
После перезагрузки снова проверьте файл. Если он уменьшился до нескольких сотен килобайт, исправление сработало, и делать больше ничего не нужно.
Переходите к следующим шагам, только если после установки июльского обновления не видно никаких изменений:
Если он всё ещё огромен, руководство Microsoft до исправления, опубликованное в той же ветке Q&A, предписывало удалить CapabilityAccessManager.db-wal из безопасного режима после остановки camsvc и не трогать все остальные файлы в папке, включая сам CapabilityAccessManager.db. Один пользователь в этой ветке вернул таким образом 276,6 ГБ.
Пользователь Reddit в r/WindowsHelp пошёл другим путём, используя среду восстановления Windows: он переименовал 200-гигабайтный файл вместо удаления, позволил Windows автоматически создать новый журнал, а старую переименованную копию удалил только после подтверждения работоспособности новой.
Неправильное удаление файла может нарушить работу Wi-Fi и разрешения камеры
Несколько пользователей в ветке Microsoft Q&A сообщили о проблемах на этом шаге. Удаление WAL-файла при работающей camsvc или ручной захват владельца папки для обхода ошибки «доступ запрещён» приводили к тому, что не отображались сети Wi-Fi, camsvc не запускалась с ошибкой 1067, а страница местоположения в настройках зависала.
Сброс разрешений с помощью команды icacls “C:\ProgramData\Microsoft\Windows\CapabilityAccessManager” /reset /T /C восстанавливал нормальную работу в этих случаях. Некоторые пользователи также потеряли сохранённые пароли Wi-Fi и были вынуждены подключаться вручную, а затем заново предоставлять доступ к камере и микрофону ранее одобренным приложениям.
Если диск уже заполнен, и Центр обновления Windows не может загрузить KB5101650, единственный вариант — сначала очистить файл. Всем остальным следует установить обновление, проверить размер файла после этого и прибегать к удалению, только если размер не уменьшился.
Пока нет комментариев. Будьте первым!