Папка WinSxS в Windows 11: почему растет объем системных файлов

Суть в том, что тревожиться стоит не о реальном объёме хранилища, а о непонимании того, как Windows устроена изнутри. Папка WinSxS растёт по заданной логике, а её видимый размер в Проводнике почти всегда завышен из-за механизма жёстких ссылок. Если посмотреть на архитектуру, станет ясно, какие именно процессы раздувают хранилище, где заканчивается реальное потребление и где начинается иллюзия.

Анатомия хранилища компонентов: зачем нужна WinSxS

WinSxS расшифровывается как Windows Side-by-Side — буквально «бок о бок». Это системная папка, в которой Windows хранит разные версии одних и тех же файлов: драйверов, библиотек, исполняемых модулей, ресурсов локализации. Идея — держать рядом несколько вариантов одного компонента, чтобы система могла гибко ими управлять. В практическом смысле это даёт три возможности, каждая из которых прямо влияет на итоговый размер папки.

Во-первых, установка и откат накопительных обновлений. Каждый месяц Microsoft выпускает пакет исправлений, который содержит все накопленные патчи безопасности и стабильности. При установке нового пакета система не перезаписывает существующие файлы, а добавляет в WinSxS обновлённые версии компонентов и переключает активные ссылки на них. Старые версии остаются в хранилище на случай отката — именно здесь начинается рост.

Во-вторых, активация и деактивация компонентов Windows. В системе можно включать и отключать отдельные модули — Internet Explorer в legacy-режиме, платформу виртуальных машин Hyper-V, подсистему Windows для Linux (WSL — Windows Subsystem for Linux, слой совместимости для запуска Linux-приложений внутри Windows). Для каждого такого компонента WinSxS держит все необходимые файлы, чтобы активация проходила мгновенно, без скачивания из интернета. Это удобство оборачивается тем, что в хранилище постоянно лежат полные наборы файлов для функций, которые пользователь, возможно, никогда не запустит.

В-третьих, восстановление повреждённых системных файлов. Если библиотека в папке System32 оказывается испорченной, Windows автоматически берёт её копию из хранилища и подменяет повреждённый экземпляр. Это самовосстанавливающийся механизм, и работает он только потому, что в WinSxS хранятся заведомо корректные версии.

WinSxS — это рабочая база системных файлов, а не мусорный кэш. Повреждение этой папки напрямую ведёт к невозможности загрузить ОС.

Иллюзия объёма: почему Проводник ошибается

Стандартный Проводник Windows и любые сторонние файловые менеджеры показывают размер WinSxS с серьёзной погрешностью. Причина — жёсткие ссылки файловой системы NTFS (New Technology File System, основная файловая система Windows начиная с версии NT). Жёсткая ссылка — это повторное имя для одного и того же физического файла на диске. У файла может быть несколько имён в разных папках, но содержимое у них одно, и место на диске занимает один экземпляр.

Механика выглядит так. Файл driver.sys физически занимает 200 МБ и лежит, например, в C:\Windows\System32\. Система также создаёт на него жёсткую ссылку в WinSxS, чтобы хранить резервную копию. Когда Проводник сканирует обе директории, он видит два файла по 200 МБ и честно складывает их, получая 400 МБ. На диске же лежит один файл, и его реальный вес — те же 200 МБ.

Когда в хранилище накоплено много компонентов с такими «зеркалами» в разных местах, арифметическая разница становится заметной. Папка может показывать 18 ГБ, а реально занимать 7 ГБ. Это не мошенничество со стороны системы — это ограничение алгоритма подсчёта, который учитывает каждое имя файла как самостоятельный объект.

Что касается сторонних программ, то почти все они работают по тому же принципу: проходят по дереву каталогов и складывают размеры найденных файлов. Ни одна из них не знает, какие из этих файлов — жёсткие ссылки на один физический экземпляр, а какие — самостоятельные объекты. Исключение составляют утилиты, которые явно умеют работать с NTFS на низком уровне, но это редкость. Поэтому тревожная картина «WinSxS сожрала половину диска» чаще всего оказывается чистой арифметикой, а не реальным расходом.

Реальный размер WinSxS можно узнать через специализированные инструменты, которые понимают природу жёстких ссылок и учитывают каждый физический файл ровно один раз. Один из таких инструментов встроен в саму Windows — утилита DISM.

Цифра в Проводнике для WinSxS — это сумма показаний по множеству жёстких ссылок, а не реальный объём на диске.

Механика роста: накопительные обновления и жизненный цикл файлов

Рост хранилища компонентов — процесс управляемый, им ведает логика обновлений. Каждый месяц Microsoft выпускает накопительные обновления безопасности — традиционно во второй вторник месяца, в обиходе это называется Patch Tuesday. Помимо них, бывают внеплановые патчи для критических уязвимостей, а раз в год — крупные функциональные релизы, например переход с 23H2 на 24H2. Все три типа поставок по-разному влияют на объём WinSxS, и понимание этой разницы — ключ к пониманию того, почему папка пухнет именно сейчас, а не через полгода.

Что именно добавляется при каждом обновлении

При установке накопительного обновления система разворачивает новую версию компонента в WinSxS и переключает активные файлы на эту версию через механизм жёстких ссылок. Старая версия остаётся в хранилище ещё какое-то время — это страховка: если обновление содержит баг и ломает систему, Windows может вернуться к предыдущей версии компонента без переустановки. Размер прибавки зависит от масштаба патча: точечные исправления безопасности могут весить несколько сотен мегабайт, а крупные ежемесячные накопительные пакеты — уже несколько гигабайт, особенно если за месяц накопилось много изменений.

Зачем хранить старые версии

Откат требуется редко, но когда он нужен — это единственный способ вернуть работоспособность без чистой переустановки. Системный администратор или продвинутый пользователь может запустить процедуру отката обновления, и Windows подменит текущие файлы на сохранённые в WinSxS более ранние версии. Если бы хранилище очищалось агрессивно сразу после каждого обновления, такая возможность пропала бы, а каждый откат превращался бы в переустановку системы.

Роль StartComponentCleanup

В Windows есть встроенная задача автоматического обслуживания StartComponentCleanup. Она запускается по расписанию через Планировщик задач и удаляет компоненты, которые старше 30 дней. Этот срок — льготный период, в течение которого откат гарантированно возможен. После 30 дней компонент считается устаревшим, и его можно удалять без потери функциональности.

У задачи есть техническое ограничение: на один запуск ей отводится не более 1 часа. Если за этот час она не успевает убрать всё накопленное, удаление продолжается в следующих циклах. В итоге система приходит к равновесному состоянию, в котором WinSxS содержит только актуальные компоненты и минимально необходимую историю. Именно эта задача — главный механизм, не дающий папке расти бесконтрольно.

Эффект крупных обновлений

Рост становится особенно заметным после установки крупных функциональных обновлений — например, перехода с Windows 11 23H2 на 24H2. В этот момент в хранилище параллельно лежат компоненты сразу двух версий ОС на период миграции. Объём WinSxS может временно вырасти на несколько гигабайт, а затем прийти в норму после нескольких циклов StartComponentCleanup. Аналогичный эффект даёт установка необязательных компонентов — языковых пакетов, дополнительных шрифтов, отладочных символов для некоторых приложений.

Почему хранилище никогда не уменьшается до нуля

Даже на свежеустановленной системе WinSxS занимает ощутимый объём — обычно несколько гигабайт. Это нормальное состояние: в хранилище уже лежат базовые компоненты текущей версии Windows, файлы для активации и деактивации встроенных функций, а также минимальный набор для отката. Полностью обнулить WinSxS нельзя — система перестанет работать. Рост выше этого базового уровня и есть тот самый объём, который накапливается из-за обновлений. Для понимания порядка: на типичной рабочей станции с годовой историей обновлений реальный размер хранилища — с учётом жёстких ссылок — редко превышает 6–8 ГБ, даже если Проводник уверенно показывает 15–18 ГБ.

Безопасная очистка: как правильно использовать DISM

Управлять хранилищем компонентов вручную — значит рисковать целостностью системы. Файлы из WinSxS нельзя удалять через Проводник, сторонние файловые менеджеры или командой del. Это приведёт к тому, что жёсткие ссылки в других папках станут «битыми»: система не сможет загрузиться или установить следующее обновление.

Для управляемой очистки в Windows есть несколько штатных механизмов. Встроенная утилита «Очистка диска» (Disk Cleanup) умеет удалять устаревшие компоненты через графический интерфейс — для большинства пользователей этого достаточно. Задача StartComponentCleanup из Планировщика задач работает автоматически и не требует вмешательства. А для детального анализа и тонкой настройки существует утилита DISM (Deployment Image Servicing and Management — средство обслуживания образов Windows), которая изначально проектировалась для подготовки и обслуживания установочных образов, но со временем обросла функциями обслуживания работающей системы. Именно DISM умеет корректно работать с жёсткими ссылками и удалять только те компоненты, которые действительно больше не нужны.

Анализ реального размера

Перед очисткой разумно проверить, сколько места занимает хранилище на самом деле. Команда:

Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore

Утилита проанализирует WinSxS с учётом жёстких ссылок и покажет фактический объём. В отчёте также появится рекомендация — можно ли безопасно выполнить очистку или хранилище находится в нормальном состоянии.

Немедленная очистка

Если ожидание 30 дней не входит в планы, используется команда:

Dism.exe /online /Cleanup-Image /StartComponentCleanup

Она удаляет компоненты, которые уже не нужны для отката, но сохраняет предыдущие версии недавно установленных обновлений, чтобы можно было выполнить откат. Это консервативный вариант: освобождается ощутимый объём, но история обновлений остаётся.

Агрессивная очистка

Для максимального сжатия хранилища добавляется ключ /ResetBase:

Dism.exe /online /Cleanup-Image /StartComponentCleanup /ResetBase

Эта команда удаляет все замещённые версии компонентов — предыдущие итерации файлов, которые были обновлены более свежими патчами — и сжимает WinSxS до минимально возможного объёма. Цена — полная потеря возможности откатить ранее установленные обновления. Если через неделю окажется, что последний патч ломает сетевой адаптер или звук, вернуть предыдущую версию уже не получится. Восстановление возможно только через чистую переустановку или откат к резервной копии системы, если она была создана заранее.

Все команды требуют прав администратора. Их нужно выполнять из командной строки, запущенной от имени администратора, либо из PowerShell с повышенными привилегиями. После выполнения стоит перезагрузить компьютер, чтобы система пересчитала привязки и физически освободила место на диске.

Прямое удаление файлов из WinSxS через Проводник или сторонние утилиты — путь к невозможности загрузить ОС. Безопасная очистка выполняется только штатными средствами: утилитой «Очистка диска», задачей StartComponentCleanup или командами DISM.

Баг 24H2: почему система показывает 8,63 ГБ фантомных данных

В октябре 2024 года Microsoft подтвердила программный дефект в Windows 11 версии 24H2, затрагивающий встроенную утилиту «Очистка диска» (Disk Cleanup). После установки свежей системы или крупного функционального обновления приложение начинает показывать в разделе очистки системных файлов запись о 8,63 ГБ неудаляемых обновлений. Эта цифра остаётся неизменной при каждом запуске очистки, что вызывает у пользователей логичное подозрение: система резервирует память и не отдаёт её.

Причина: новая модель поставки обновлений

Контекст появления дефекта — новая модель поставки обновлений в 24H2, известная как Checkpoint Updates (контрольные обновления). Microsoft перешла на инкрементальную схему: первый пакет в цикле поставляется целиком и служит контрольной точкой, а последующие содержат только разницу относительно неё. Это сокращает объём загрузки и ускоряет установку — обновлять нужно лишь дельту, а не весь пакет каждый раз.

Однако механизм очистки диска пока не научился корректно учитывать эту новую механику. Он сообщает об объёме, который физически не занят: при подсчёте учитываются метаданные контрольных точек, которые не соответствуют реальным файлам на диске.

Что делать пользователю

Суть проблемы сводится к ошибке отображения, а не к реальному расходу дискового пространства. На практике запуск утилиты «Очистка диска» или задачи StartComponentCleanup может нормализовать отображение записи в отчёте, однако гарантировать исчезновение значения нельзя — поведение зависит от конкретной конфигурации и набора установленных обновлений.

Microsoft зафиксировала дефект в октябре 2024 года и работает над его исправлением в одном из будущих накопительных обновлений. Точные сроки выпуска патча, полностью устраняющего проблему на всех конфигурациях, на момент публикации не объявлены. До этого момента пользователям не нужно предпринимать никаких специальных действий: достаточно дождаться штатной работы задачи автоматического обслуживания или один раз запустить очистку диска от имени администратора. В обоих случаях отображение имеет шансы нормализоваться без ручного вмешательства.

8,63 ГБ неудаляемых обновлений в Windows 11 24H2 — ошибка отчёта Очистки диска, а не реально занятое место на диске.

Что в итоге

WinSxS — это не балласт, а рабочий механизм Windows, без которого система не смогла бы обновляться, откатываться и восстанавливаться после сбоев. Рост папки — следствие естественного жизненного цикла обновлений, а завышенные цифры в Проводнике — эффект жёстких ссылок, которые стандартные файловые менеджеры не умеют правильно интерпретировать. Понимание этой механики снимает тревогу и позволяет действовать разумно: вместо ручной чистки использовать DISM для анализа и контролируемой очистки, а при появлении фантомных гигабайт в отчёте Очистки диска в 24H2 — помнить, что это лишь дефект отображения, а не реальная утечка дискового пространства.

Прогноз здесь спокойный. По мере того как Microsoft переводит обновления на инкрементальную модель Checkpoint Updates, дефект с отображением будет исправлен в одном из ближайших накопительных обновлений, а сама логика хранения компонентов продолжит эволюционировать в сторону меньшей заметности для пользователя. Инструменты DISM останутся основным каналом управления хранилищем надолго — это проверенная временем часть архитектуры Windows, к которой стоит относиться как к штатному средству диагностики, а не как к аварийному инструменту последней надежды.