Куда уходит место, в какие города: почему память на диске в Windows 11 пропадает сама собой

Вопрос, куда девается место на системном диске, стабильно всплывает ну практически у всех. Им задаются даже те, кто в компьютерах разбирается на уровне выше среднего. Да и чего же тут зазорного? Купили вы, скажем, терабайтный SSD, поставили на него штук 10 программ да пару игр, а свободно из них в лучшем случае осталось процентов 15-20. Человек, понятное дело, лезет в настройки, чтобы понять, что к чему, находит там строчку про системные файлы на 90 ГБ и уходит ровно с тем же вопросом, с которым пришел. Что это за файлы такие и почему их девяносто, Windows не объясняет.

А этим летом ситуация усугубилась еще больше. В июльском KB5101650 Microsoft включила Point-in-Time Restore, и включила, что характерно, сразу всем. На первый взгляд, вроде полезно: система теперь сама делает снапшоты, чтобы вы могли откатить ее целиком, даже если она не грузится. Но, если подумать, получается не все так однозначно. Ведь под эти снапшоты нужно место, и берет система под них до 2% системного диска. А это, ни много ни мало, 20 ГБ от терабайта. Плюс сам пакет обновления весит 4,8 ГБ для 24H2 и 5,38 ГБ для 25H2. Так что если этим летом диск у вас неожиданно похудел, вас не сглазили. Так и было задумано. Давайте разбираться, куда все уходит, что можно вернуть и что трогать не надо, даже если очень хочется.

Почему все счетчики врут

И сразу спойлер: нормального инструмента, который покажет, кто именно съел место, в Windows просто нет. Раздел памяти в настройках сваливает все непонятное в кучу системных и зарезервированных файлов, а Проводник, если ходить по папкам ручками (вернее ножками), вам, конечно, посчитает, но сделает это неправильно.

Почему? Да просто NTFS устроен таким образом, что один и тот же набор байтов может числиться сразу в нескольких папках. Причем это не копии, а именно ссылки на одни и те же данные. Проводнику же об этом никто не говорит, поэтому при подсчете он складывает все подряд, так что одни и те же гигабайты он вам посчитает и в System32, и в WinSxS. Из вот такой неизбирательности, кстати, и рождаются папки весом по 15-20 ГБ, которые вроде как надо срочно сносить.

Так что начинать надо не с настроек и не с Проводника, а с WizTree или TreeSize. WizTree читает MFT напрямую, поэтому терабайтник просканирует секунд за пять, да и жесткие ссылки посчитает как положено. И вот когда перед глазами будет честная картина, можно уже предметно разбираться с каждым, кто там сидит. И начнем мы с папки, на которую грешат чаще всего.

WinSxS: папка, которую все хотят удалить

Пальцем в таких разговорах первым делом показывают именно на нее. Ну, а что? У всех же было: заходишь в C:\Windows\WinSxS, смотришь свойства, а там 12 ГБ. Первое желание, которое возникает в таких случаях, – сразу все удалить. Авось и скорость SSD вырастет.

А вот не надо. WinSxS – это хранилище компонентов, из которых система, собственно, и собрана. Файлы, которые вы видите в System32, физически лежат именно в нем, а в самой System32 на них стоят те самые жесткие ссылки. Так что, вычистив WinSxS, вы удалите не копию, а оригинал, и получите систему, которая либо не загрузится, либо не обновится. Причем выяснится это не сразу, а, скажем, через месяц, когда прилетит очередной апдейт. Вот тогда и вспомните, что чистили. Или не вспомните. Но в любом случае будет уже поздно.

Хотя посмотреть-то реальный размер можно всего лишь одной командой в терминале с правами админа:

DISM /Online /Cleanup-Image /AnalyzeComponentStore

В ответ прилетит несколько строк, и смотреть надо на четыре из них:

• Windows Explorer Reported Size – это то самое вранье Проводника.

• Actual Size of Component Store – сколько занято на самом деле.

• Shared with Windows – та часть, которая уже посчитана в других папках, то есть дополнительно ничего не занимает.

• А вот сумма Backups and Disabled Features и Cache and Temporary Data – это и есть настоящий балласт, то бишь старые версии компонентов, оставшиеся после обновлений.

Но главное даже не это, а строчка Component Store Cleanup Recommended, которая прямым текстом говорит, есть ли вообще смысл что-то чистить. В примере из документации Microsoft Проводник показывает 4,98 ГБ, из которых реально занято 4,88, а балласта там всего-то 507 МБ.

Чистится вся эта история тоже штатно:

DISM /Online /Cleanup-Image /StartComponentCleanup

Так, скажете вы. Стоп. Ведь еще же есть ключ /ResetBase, который выносит вообще все старые версии. Но не спешите, потому как после него вы не сможете удалить ни одно из уже установленных обновлений. Пока все работает стабильно, оно вроде и ладно. А вот если через неделю прилетит кривой патч, откатывать его будет уже нечем.

Да и сколько там вернется-то? Ну, в лучшем случае пара гигабайт, а то и того меньше. Не 10 и тем более не 30. К тому же Windows и сама его чистит по расписанию. Просто задача эта запускается в простое, так что если вы свой ПК регулярно выключаете, руки у системы до дела могут не доходить месяцами. Так что не глушите машину раньше времени и будет ок.

Хуже, когда хранилище повреждено. Тогда StartComponentCleanup доходит до какого-нибудь процента, падает с ошибкой, и места вы не видите вообще. Лечится через DISM /Online /Cleanup-Image /RestoreHealth, а если и это не помогло, то дальше только накатывать систему поверх с сохранением файлов.

Почему обновления стали весить как игра

Раз уж речь зашла про балласт, надо бы объяснить, откуда он вообще берется. Устроено это так. Ежемесячные обновления Windows кумулятивные – то есть тащат в себе все изменения с момента выхода версии. И раньше они считались как двоичные разницы от исходных файлов RTM-сборки. А чем дальше от релиза, тем длиннее цепочка и толще пакет.

С 24H2 Microsoft ввела checkpoint-обновления. Смысл в том, что вместо одной базы от RTM система периодически ставит промежуточные точки, и следующие патчи считаются уже от них. Идея-то здравая, вот только все контрольные точки надо ставить по порядку. Так что машина, которая полгода не обновлялась, при включении вытянет на себя весь этот состав.

На ИИ в этой истории грешат чаще всего, и отчасти заслуженно. Начиная с 24H2 в пакет кладут модели для Copilot+ – поиск по картинкам, извлечение контента, семантический анализ, – и тянут они примерно 3 ГБ. Правда, ставятся эти компоненты только на Copilot+ ПК, так что на обычной машине места они не займут, зато вес самого msu раздувают исправно.

Основная же причина в другом: контрольную точку с сентября 2024 года так и не обновили. То есть механика, которую придумали как раз против разрастания пакетов, по факту не сработала. В мае 2025-го обновление скакнуло с 1,3 до 4,4 ГБ и с тех пор только росло. Отсюда и июльский пакет на 5 ГБ.

Плюс ко всему система резервирует под свои нужды еще около 7 ГБ под так называемый Reserved Storage, когда место занимается под будущие обновления, временные файлы и кэш, чтобы апдейт не встал колом на забитом диске. Отключить его, конечно, можно командой DISM /Online /Set-ReservedStorageState /State:Disabled. Вот только обновление, которому не хватит места, просто не установится, и узнаете вы об этом последним.

Гибернация: самая большая трата, о которой не думают

Файл C:\hiberfil.sys – это место, куда система скидывает содержимое оперативки, когда уходит в гибернацию. Логика тут простая: сколько у вас памяти, столько и нужно места на диске.

По нынешним правилам полный файл занимает порядка 40% от объема ОЗУ, а сокращенный – около 20%. А теперь давайте посчитаем. 32 ГБ памяти – это 13 ГБ на диске. 64 ГБ – уже 25. Причем это не запас на будущее, а занято прямо сейчас и висит там постоянно.

Но помните ли вы, когда в последний раз отправляли десктоп в гибернацию? Вот и я о том же. А файл все равно лежит, и все потому, что его использует быстрый запуск. Это та самая штука, из-за которой завершение работы на самом деле никакое не завершение: ядро и драйверы сохраняются в тот же файл, чтобы в следующий раз стартовать побыстрее. Отсюда, кстати, и вечный совет при глюках перезагружаться, а не выключать и включать. Перезагрузка дает честный холодный старт, а выключение только делает вид.

Дальше есть два варианта, смотря что вам дороже:

powercfg /hibernate off

Файл удаляется, гигабайты возвращаются. Вместе с ним, правда, уходят гибернация, быстрый запуск и гибридный сон. Но на десктопе, который вы и так перезагружаете, потеря, прямо скажем, небольшая.

powercfg /h /type reduced

Файл ужимается примерно вдвое, быстрый запуск остается, а вот гибернация из меню питания пропадает.

Вручную hiberfil.sys удалять бесполезно. Он защищен системой, и если вы его выпилите, Windows создаст его заново.

Место при этом – не единственная причина от него избавиться. Раз при каждом выключении в этот файл пишется ядро с драйверами, то каждое выключение – это еще и запись на диск. Не десятки гигабайт, конечно, но при паре циклов в день за год набегает прилично. Для терабайтника капля, а вот для дешевого QLC на 256 ГБ в ноутбуке – уже повод задуматься.

Точки восстановления и новый Point-in-Time Restore

Служба VSS работает совсем не так, как думает большинство. Она не копирует файлы целиком, а сохраняет блоки, которые изменились уже после создания снапшота. Поэтому и хранилище растет не от установки программ, а от работы с большими файлами. Смонтировали образ, поработали с проектом на 50 ГБ, перезаписали виртуальный диск – и снапшоты распухли, хотя ставить вы ничего не ставили.

По умолчанию VSS разрешено занимать до 10% тома, вот только лимит этот иногда оказывается не выставлен вовсе. Смотрим:

vssadmin list shadowstorage

В ответ прилетят три цифры: сколько используется сейчас, сколько выделено и какой стоит потолок. Если вместо потолка написано UNBOUNDED, а места на диске кот наплакал, то это ваш случай. Ограничиваем:

vssadmin resize shadowstorage /for=C: /on=C: /maxsize=15GB

Если снапшоты уже занимают больше нового лимита, система прибьет самые старые, пока не уложится. Только полностью выключать защиту системы я бы все равно не стал. Именно из-за отсутствия точки восстановления люди потом и переустанавливают Windows после неудачного драйвера.

На этой же VSS, кстати, работает и Point-in-Time Restore, с которого мы начали.

Поэтому выставляй лимиты, не выставляй, а система все равно сделает по-своему: поставили вы себе через защиту системы 6%, а она втихую вернула их к своим 2% и снесла старые точки, чтобы уложиться.

Причем делает она это, даже когда сама выключена. Так что если точки восстановления у вас пропадают сами собой, а вы уже начали грешить на антивирус, то виноватого ищите именно здесь. Ну а если вы точно знаете, что откатываться будете из бэкапа, то Point-in-Time можно смело вырубать в параметрах, в разделе восстановления. Это законный способ вернуть себе десятки гигабайт.

Три кэша шейдеров, которые все путают

У тех, кто играет, к системным едокам добавляется еще один. Конечно же, речь о скомпилированных шейдерах, которые кэшируются, чтобы системе не приходилось собирать их заново при каждом запуске, и мест для этого целых три. 

• Первое – системный DirectX Shader Cache, он же D3DSCache в профиле пользователя. Весит обычно 50–500 МБ, чистится галочкой в очистке диска и никому не мешает.

• Второе – кэш драйвера. У NVIDIA это %LocalAppData%\NVIDIA\DXCache и GLCache, и вот тут уже разрастается будь здоров. После нескольких смен драйвера и пары десятков игр там спокойно набирается 5–15 ГБ, причем добрая половина – мусор от старых версий, который уже никогда и никому не пригодится. Штатная очистка диска эти папки не трогает вообще, а вот руками их вычистить можно смело. Драйвер соберет кэш заново, просто игры первый раз будут запускаться подольше. Заодно в панели NVIDIA есть параметр Shader Cache Size, где по умолчанию стоит неограниченный размер. Поставьте 10 ГБ и живите спокойно.

• Третье – кэш Steam, steamapps\shadercache. Это уже про Vulkan и предзагрузку шейдеров, и рекорды там знатные. В обсуждениях No Man's Sky люди находили у себя по 60–70 ГБ в одном файле steamapp_pipeline_cache.foz. Лечится через настройки Steam: отключаете предзагрузку шейдеров и сносите папку конкретной игры.

Стоит ли вообще чистить кэш? Стоит, и еще как. Но не только ради гигабайтов. Просто когда в нем копятся записи от десятка старых драйверов, поиск по ним начинает стоить времени, и в тяжелых сценах это вылезает рывками. Так что если у вас статтеры, а VRAM с процессором ни при чем, не поленитесь – загляните сюда. Иногда помогает.

Мелочи, которые внезапно оказываются не мелочами

Оставшиеся два едока встречаются пореже, но от этого не менее обидны.

Первый – файл CapabilityAccessManager.db-wal. Это журнал, куда Windows пишет, какое приложение когда лезло к камере, микрофону и геолокации. У части людей он разрастался до совсем уж неприличных размеров и жрал место безо всяких объяснений. Пофиксили это в том же июльском KB5101650. Так что если место у вас утекает непонятно куда, а обновление еще не стоит, вот вам и повод его накатить.

Второй – папка Windows.old. Появляется она после обновления версии системы, весит легко 20–30 ГБ и через десять дней удаляется сама. Все это время из нее можно откатиться на прежнюю версию, ради этого она, собственно, и лежит. А если ждать неохота, сносите через очистку диска, пунктом про предыдущие установки Windows. А вот ручками не лезьте: там свои права доступа, так что обычным удалением вы наживете себе только гору ошибок.

Ну а если все перечисленное вы уже вычистили, а места все равно нет, остается compact.exe /CompactOS:always. Это штатное сжатие системных файлов прямо на месте, придуманное для устройств с совсем уж маленькими дисками. Отдает несколько гигабайт в обмен на небольшую нагрузку на процессор при чтении. На ноутбуке с eMMC или SSD на 128 ГБ – вариант вполне рабочий, а на нормальной машине связываться смысла немного.

Что делать по итогу

Порядок действий выходит примерно такой:

1. Посмотреть на диск честно. WizTree или TreeSize, а не Проводник и не раздел памяти в настройках.

2. Гибернация. Если оперативки много, это сразу десятки гигабайт. powercfg /hibernate off или хотя бы /type reduced.

3. Point-in-Time и теневые копии. Тоже десятки. Лимит через vssadmin resize shadowstorage, а сам Point-in-Time при желании вырубается в параметрах.

4. Кэш драйвера видеокарты и Steam. Единицы гигабайт, а иногда и десятки. Заодно ограничить размер в панели NVIDIA.

5. Windows.old, если он еще не самоудалился. Только через очистку диска.

6. И только потом WinSxS через DISM, потому что там как раз меньше всего.

Ну и заодно гляньте, что вообще лежит у вас в пользовательских папках. Бывает, что все эти системные пляски меркнут на фоне забытой распаковки архива на 80 ГБ.

А чего делать не стоит, так это чистить WinSxS ручками, сносить hiberfil.sys в обход powercfg, вырубать защиту системы целиком ради пары гигабайт и ставить чистильщики с сомнительных сайтов, которые обещают освободить 50 ГБ. Все, что можно вернуть, возвращается штатными средствами минут за десять. Без бубна и танцев.

Ну и держите в голове, что часть места у вас занята не просто так. Reserved Storage лежит, чтобы обновление не встало посреди установки. Точки восстановления – чтобы не переустанавливать систему после кривого драйвера. WinSxS – чтобы обновления вообще ставились. Так что вопрос тут не в том, как отжать у Windows каждый гигабайт, а в том, за что вы платите местом осознанно, а за что просто по незнанию.