winsxs что это за папка 🔥 Pinme.ru

WinSxS — это системное хранилище компонентов Windows (Component Store), расположенное по пути C:WindowsWinSxS. В нём в виде «сторонних рядом» (side-by-side) сборок хранятся версии системных файлов, манифесты, каталоги безопасности и связанные ресурсы, необходимые для установки, обслуживания (servicing), обновления и отката компонентов Windows 🧱. Папка WinSxS обеспечивает совместное существование нескольких версий одной и той же компоненты, позволяя включать/отключать функции, устанавливать и откатывать обновления без конфликтов и «DLL-ада». Это фундаментальный механизм целостности и обслуживаемости ОС, который нельзя заменять простым набором файлов из System32.

Зачем нужен WinSxS и как он устроен 🗂️

Хранилище компонентов решает сразу несколько задач: хранит «материнские» копии системных компонентов, поддерживает целостность через манифесты и каталоги, позволяет одновременно иметь разные версии библиотек и драйверов, а также управляет связями с рабочими копиями в System32, SysWOW64 и других каталогах. Многие файлы, которые вы видите в System32, являются жёсткими ссылками (hardlinks) на физические экземпляры в WinSxS 🔗.

Каждый компонент в WinSxS идентифицируется по уникальному имени (component identity), включающему архитектуру (amd64, x86), имя пакета (microsoft-windows-…), язык/локаль (ru-RU, en-US), номер версии и хэш. Иерархия папок отражает эту идентичность: например, amd64_microsoft-windows-kernel32_31bf3856ad364e35_10.0.22621.2283_none_... 🧩. Рядом располагаются:

Manifests — XML-описания состава и зависимостей компонентов.
Catalogs — криптографические каталоги (.cat) для проверки подлинности файлов.
Backup — резервные метаданные для критических операций обслуживания.

Размер WinSxS: мифы, факты и жёсткие ссылки 🧮

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

Проверить фактический вес хранилища компонентов можно через DISM:

DISM /Online /Cleanup-Image /AnalyzeComponentStore

Отчёт покажет реальную «уникальную» ёмкость хранилища, объём кандидатов для очистки и рекомендации. Используйте /AnalyzeComponentStore для объективной оценки размера и не ориентируйтесь исключительно на свойства папки в проводнике.

Типовая структура WinSxS и роль элементов ⚙️

Элемент	Пример расположения	Назначение	Можно ли удалять вручную?	Корректный способ очистки	Риски удаления
Компонентные папки	C:WindowsWinSxSamd64_microsoft-…	Хранение версий системных DLL, EXE, драйверов	Нет	DISM StartComponentCleanup	Порча ОС, невозможность обновлений
Manifests (*.manifest)	C:WindowsWinSxSManifests	Описание состава, зависимостей, политики	Нет	Автоматически обслуживается	Нарушение целостности CBS
Catalogs (*.cat)	C:WindowsWinSxSCatalogs	Проверка подписи файлов, доверие	Нет	Автоматически обслуживается	Провал верификации, сбои обновлений
Pending/Temp	Внутри WinSxS	Промежуточные данные для транзакций	Нет	Завершить обслуживание, перезагрузка	Незавершённые обновления
Языковые ресурсы	…_ru-ru, …_en-us	Локализация компонентов	Нет	Удалить пакеты языков штатно	Проблемы локализации интерфейса
Служебные логи CBS	C:WindowsLogsCBS (не WinSxS)	Журналы обслуживания	Частично	Обрезка логов, очистка средствами системы	Потеря трассировки проблем
Hardlinks	System32 ⇄ WinSxS	Одна физическая копия — несколько путей	—	—	Счётчики размера вводят в заблуждение

Безопасные способы уменьшить размер WinSxS 🧹

Уменьшение объёма хранилища компонентов должно выполняться строго штатными инструментами Windows. Никогда не удаляйте вручную папку WinSxS или её содержимое — это почти гарантированно приведёт к повреждению обслуживаемости и невозможности установки обновлений 🚫.

Анализ и очистка хранилища компонентов (DISM)
```
DISM /Online /Cleanup-Image /AnalyzeComponentStore
DISM /Online /Cleanup-Image /StartComponentCleanup
```
Первая команда анализирует, вторая — удаляет устаревшие версии компонентов, уже заменённые новыми. Это снижает объём и не нарушает возможность отката последних обновлений.
Ускоренная очистка с отказом от отката обновлений (для обслуживаемых серверов/киосков по политике)
```
DISM /Online /Cleanup-Image /StartComponentCleanup /ResetBase
```
Фиксирует текущую базу компонентов, убирая старые версии и делая невозможной деинсталляцию обновлений. Подходит для «запечатанных» образов. Команда /ResetBase необратима.
Удаление неиспользуемых функций и языков 📦
```
Dism /Online /Get-Features /Format:Table
Dism /Online /Disable-Feature /FeatureName:ИмяФункции /Remove
Dism /Online /Get-Intl
Dism /Online /Remove-Capability /CapabilityName:Language.Basic~~~ru-RU~0.0.1.0
```
Отключайте и удаляйте пакеты, которые точно не нужны (например, неиспользуемые языки, функции Hyper-V на клиентских машинах и т. п.). Это освобождает место, так как соответствующие компоненты хранились в WinSxS.
Автоматическая плановая задача ⏳

В Windows 8/8.1/10/11 есть плановая задача MicrosoftWindowsServicingStartComponentCleanup, которая периодически запускается в простое. Убедитесь, что планировщик работает и устройство не мешает обслуживанию (например, не отключайте питание в процессе).

Почему после очистки размер «не меняется» в Проводнике? 🔎

Из-за жёстких ссылок наблюдается иллюзия: рабочие копии в System32 и «матрица» в WinSxS часто ссылаются на один и тот же физический файл. После очистки DISM может убрать предыдущие версии, но текущая версия всё ещё учитывается в сумме обоих путей. Измеряйте размер через DISM /AnalyzeComponentStore, а не через свойства папок. Для дополнительной проверки можно использовать команды:

fsutil hardlink list C:WindowsSystem32kernel32.dll

и сравнить список ссылок; также полезны утилиты подсчёта реального дискового использования, которые учитывают hardlink’и.

WinSxS и обновления: откаты, безопасность и целостность 🛡️

WinSxS хранит базовые версии и обновления для возможности отката к предыдущему состоянию. Когда выходят новые cumulative updates, старые версии становятся кандидатами на очистку. Манифесты и каталоги гарантируют, что каждый файл соответствует политике и подписи производителя. Если вручную удалить части WinSxS, система теряет способность корректно обновляться, проверять подписи и, в итоге, может перестать загружаться.

При подозрении на повреждение хранилища используйте связку SFC/DISM:

sfc /scannow
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

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

Различия по версиям Windows и дополнительные технологии 💡

Начиная с Windows Vista, WinSxS стал центром обслуживания системы. В Windows 7 добавили очистку через компонент «Очистка диска» (Windows Update Cleanup). В Windows 8/10/11 развили автоматические задачи и DISM-параметры. В современных версиях Windows компоненты могут быть дополнительно сжаты (WOF/CompactOS), если место на диске ограничено, и это не то же самое, что принудительное NTFS-сжатие. Применять NTFS-сжатие к WinSxS вручную не рекомендуется: это может ухудшить производительность и осложнить обновления.

Функции по требованию (Features on Demand) и Capabilities (например, шрифты, языки, компоненты .NET) могут хранить свои payload’ы в WinSxS или подтягиваться из центров обновления при включении. Чтобы экономить место, администраторы иногда удаляют «локальные исходники» и указывают альтернативные источники при последующем включении функции. Это управляется через DISM и политики.

Мифы и факты о WinSxS 🧠

Миф: «WinSxS — это дубль System32». Факт: System32 часто ссылается на «мастер-копии» в WinSxS через жёсткие ссылки; WinSxS — первичный источник.
Миф: «Можно просто удалить старые папки по дате». Факт: даты не отражают связей зависимостей; удаление нарушит обслуживаемость.
Миф: «Размер можно уменьшить в два раза». Факт: падение «на глаз» в проводнике некорректно; уменьшение зависит от накопленных обновлений и возможностей очистки.
Миф: «DISM опасен». Факт: штатные команды DISM и плановые задачи — поддерживаемый и безопасный путь, если следовать рекомендациям.

Практические сценарии обслуживания и команды 🔧

Ниже — небольшой набор команд, применимых в повседневной практике админа и продвинутого пользователя:

:: Анализ состояния хранилища компонентов
DISM /Online /Cleanup-Image /AnalyzeComponentStore

:: Удалить устаревшие версии компонентов
DISM /Online /Cleanup-Image /StartComponentCleanup

:: Удалить устаревшие версии и зафиксировать базу (без возможности отката)
DISM /Online /Cleanup-Image /StartComponentCleanup /ResetBase

:: Очистка кэша обновлений (если повреждён)
net stop wuauserv
net stop bits
rd /s /q %windir%SoftwareDistribution
net start wuauserv
net start bits

:: Проверка и восстановление целостности
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

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

Как читать имена папок в WinSxS и понимать версии 🔬

Возьмём пример: amd64_microsoft-windows-kernel32_31bf3856ad364e35_10.0.22621.2283_none_... — здесь amd64 означает архитектуру, далее идёт имя компонента microsoft-windows-kernel32, затем публичный ключ издателя (31bf3856ad364e35 у Microsoft), версия ОС/компонента (10.0.22621.2283), а в конце — маркеры нейтральности или языковой папки. Эта структура помогает системе сопоставлять зависимости, проверять подлинность и правильно «подкладывать» файлы в рабочие директории при включении функций и установке обновлений.

Диагностика проблем WinSxS и логирование 🧪

Основные журналы обслуживания — в C:WindowsLogsCBSCBS.log и связанных файлах. При неудачных обновлениях проверяйте CBS, WindowsUpdate.log (в новых версиях формируется через PowerShell), а также события в Журнале Windows (Setup, Servicing). Если DISM сообщает о повреждении, которое не удаётся исправить, может понадобиться указать источник с эталонными файлами (install.wim с той же версией ОС) через параметр /Source и /LimitAccess. В корпоративной среде источники часто централизуются на WSUS/SCCM или через локальные репозитории.

FAQ по смежным темам

Можно ли переместить или перенести папку WinSxS на другой диск с помощью символической ссылки?

Перемещение WinSxS или подмены на символические/жёсткие ссылки крайне не рекомендуется. Этот каталог задействован ранними стадиями загрузки и комплексом обслуживания, включая проверку подписи и привязку к конкретным NTFS-атрибутам. Попытки переноса часто приводят к нестабильности, невозможности устанавливать обновления, а иногда — к нерабочей системе после перезагрузки. Windows не поддерживает сценарии, где «Component Store» вынесен на другой том как обычная пользовательская папка. Даже если удастся создать перенаправления, часть системных сервисов ожидает прямой доступ к путям и дескрипторам без переадресации. Виртуализация папки также может нарушить права доступа и опечатанные ACL. В редких сценариях корпоративной кастомизации такие попытки предпринимают, но сопровождаются значительным риском и отсутствием поддержки. Правильный путь экономии места — корректная очистка DISM, удаление ненужных возможностей и языков, а также использование более ёмкого системного тома.

Чем отличаются WinSxS и System32, если многие файлы фактически одни и те же?

WinSxS — это «хранилище истины», где содержатся версии компонентов и их метаданные. System32 — это рабочая поверхность, куда обслуживающая система «проецирует» активные версии файлов через жёсткие ссылки. Таким образом, когда вы «видите» файл в System32, он на самом деле физически принадлежит WinSxS. Такое разделение позволяет обновлять и откатывать отдельные части ОС без конфликтов и подмен. Если выходит новая версия компонента, WinSxS добавляет её рядом со старой, а рабочие ссылки перестраиваются на актуальные экземпляры. Это и есть концепция side-by-side: разные версии могут сосуществовать, а система управляет тем, какая из них активна. Такое устройство резко снизило количество проблем типа «DLL Hell», свойственных старым системам.

Почему иногда после крупных обновлений Windows папка WinSxS заметно растёт?

Крупные кумулятивные обновления добавляют новые версии множества компонентов, оставляя прежние как кандидаты на откат. Пока система не сочтёт их безопасными для удаления, они будут занимать место. Плановая задача StartComponentCleanup или ручной запуск DISM обычно приводят к сокращению объёма спустя некоторое время. На серверных системах политики могут задерживать очистку, чтобы дать администраторам окно для отката. Также на размер влияют установленные языки, опции .NET, графические и мультимедийные компоненты. В итоговом балансе важно помнить о жёстких ссылках: видимый рост в Проводнике не всегда равен реальному уникальному потреблению. Итоговую картину даёт только анализ через /AnalyzeComponentStore и метрики дискового уровня.

Стоит ли использовать NTFS-сжатие или сторонние утилиты для уменьшения WinSxS?

Принудительное NTFS-сжатие WinSxS может ухудшить производительность, осложнить установку обновлений и увеличить время обслуживания. Сторонние утилиты, «чистящие» WinSxS без участия DISM, часто удаляют критические манифесты и каталоги, что приводит к поломке обслуживания. Windows использует собственные механизмы оптимизации, включая CompactOS и WOF, которые понимают специфику системных файлов и корректно интегрируются с обновлениями. Такие механизмы автоматически применяются при дефиците места или по команде администратора, не ломая зависимостей. На серверах с высокой нагрузкой компрессия системных путей вообще не рекомендуется. Если нужно снизить объём, действуйте через отключение/удаление неиспользуемых функций и языков, а также через DISM-очистку. Итоговый выигрыш будет безопасным и поддерживаемым.

Как понять, что хранилище компонентов повреждено, и что делать дальше?

Признаками повреждения являются ошибки установки обновлений, сообщения DISM о несоответствии хэшей, неудачи SFC и записи об ошибках в CBS.log. Начните с проверки sfc /scannow, затем выполните DISM /Online /Cleanup-Image /ScanHealth и при необходимости /RestoreHealth. Если DISM не находит подходящие источники в самой системе, укажите эталонный install.wim той же редакции и сборки с помощью параметра /Source. Проверьте целостность хранилищ сертификатов и работу службы криптографии, так как каталоги (.cat) участвуют в проверке подлинности. В некоторых случаях проблему создают сбойные драйверы или антивирус, блокирующий доступ к системным каталогам — их стоит временно отключить на время обслуживания. После восстановления повторите SFC, чтобы убедиться в соответствии всех системных файлов эталону. Если ошибки сохраняются, проверьте журнал событий и рассмотрите восстановление из образа или «сброс» с сохранением файлов.