Component store windows 7

Manage the Component Store

“Why is WinSxS so large?” has been asked by many Windows users. While this question has been discussed in blog posts, this topic goes into a little more details about the concepts behind the component store (specifically the WinSxS folder) and then provides links to topics that highlight ways to better manage the size of the WinSxS folder.

The short answer is that the WinSxS folder isn’t as large as it may appear at first glance because size calculations can include Windows binaries located elsewhere which makes the WinSxS folder seem larger than it really is.

The Windows component store and WinSxS folder

The WinSxS folder is located in the Windows folder, for example c:\Windows\WinSxS. It’s the location for Windows Component Store files. The Windows Component Store is used to support the functions needed for the customization and updating of Windows. Here are some examples of how the Windows Component Store files are used:

Using Windows Update to install new component versions. This keeps systems secure and up-to-date.

Enabling or disabling Windows features.

Adding roles or features using Server Manager.

Moving systems between different Windows Editions.

System recovery from corruption or boot failures

Uninstalling problematic updates

Running programs using side-by-side assemblies

The Windows Component Store was first introduced in WindowsВ XP to support side by side assemblies. Beginning in WindowsВ Vista, the component store was enhanced to track and service all of the components that make up the operating system. Those different operating system components track objects such as files, directories, registry keys, and services. Specific versions of components are then collected together into packages. Packages are used by Windows Update and DISM to update Windows. The components and packages used in a Windows installation are processed by the Windows Component Store. Determining the size of the Windows Component Store is complicated by the fact that many of the files are used by Windows from directories outside the Windows Component Store using a technique known as hard linking. In such cases, the files from a component version appear both inside and outside the Windows Component Store. By using hard linking Windows is able to appear to keep multiple copies of the same file without actually taking the added space for multiple copies.

Hard links

A hard link is a file system object which allows two files to refer to the same location on disk. This means that more than one file can refer to the same data and changes to that data in one file are reflected in the other files. This complicates notions of directory size as can be seen using the following example:

Directory A has three files: 1.txt, 2.txt, and 3.txt

Directory B has one file: 4.txt

Files 1.txt and 2.txt are hard linked together and contain 1MB of data.

Files 3.txt and 4.txt are also hard linked together and contain 2MB of data.

In this example, you can see that the hard links enable multiple files to refer to the same set of data.

Now what is the size of directory A?

The answer depends on what you plan to do with directory A:

If you read the files in the directory A then the size of all the files that are read is the sum of each file size. In this example, that would be 4 MB.

If you copy all the files from directory A to a new location, then the amount of data copied is the sum of all data hard linked from the files. In this example, that would be 3 MB.

If you are trying to free up space by deleting the directory A, you will only see a reduction in size for the files that are hard linked only by directory A. In this example, this amounts to a savings of 1 MB.

Back to the question of how much space is used by the Windows Component Store, and specifically the WinSxS folder. The third answer in the directory A example, most closely matches how much extra space is used. Files hard linked to the rest of the system are required for system operations, so they should not be counted, and files hard linked to multiple locations within the component store should only have the size stored on disk counted.

Managing the Windows Component Store

You can use new features in Windows 8.1 and WindowsВ Server 2012 R2 to manage the Windows Component Store:

Источник

Восстановление хранилища компонентов

Поскольку в современных версиях операционной системы Windows (начиная с Vista) компонентная модель является одной из ключевых файловых структур, обеспечивающих бесперебойную работу системы, поддержание её в рабочем состоянии крайне критично для нормальной работы исполнительной подсистемы Windows. Тем не менее, на протяжении жизненного цикла операционной системы, хранилище компонентов может повреждаться. Основные причины повреждения хранилища компонентов заключаются в том, что:

• в процессе обновления операционной системы могут повреждаться/удаляться файлы компонентов в местоположениях: %SYSTEMROOT%\Servicing\Packages и %SYSTEMROOT%\WinSxS ;
• в процессе обновления операционной системы могут повреждаться/удаляться ветви/ключи реестра по путям: HKLM\Components , HKLM\Schema и HKLM\Software\Microsoft\Windows\CurrentVersion\Component Based Servicing ;

описанные причины могут быть следствием более глобальных сбоев:

• Ошибки при передаче файлов по сетевому интерфейсу;
• Ошибки дисковой/файловой подсистем;
• Аппаратные сбои: ошибки чтения/записи оперативной памяти, сбои в любых иных аппаратных компонентах;
• Ошибки в работе сторонних инструментов оптимизации: средства очистки реестра, оптимизации файловой системы, оптимизации хранилища компонентов, оптимизации каталога распространения и прч.
• Ошибки в коде модулей компонентов Центра обновления Windows;

Подобные дефекты хранилища компонентов WinSxS могут выявляться при попытках пользователя произвести обновление системы (например, через установку обновления безопасности):

Или же могут быть выявлены в процессе работы разнообразных диагностических и сервисных утилит (модули, входящие в состав Центра обновления Windows), о чем в лог-файлах нам красноречиво сигнализирует статус ERROR_SXS_COMPONENT_STORE_CORRUPT . Описанные выше проблемы впоследствии становятся причиной возникновения различного рода отказов установки обновлений. Чаще всего повреждаются *.cat , *.mum , *.manifest и *.dll -файлы. Все найденные методы восстановления хранилища компонентов я решил выделить в отдельные статьи, а тут попробовать организовать что-то вроде своеобразного хаба.

Этапы восстановления хранилища компонентов

Итак, для восстановления хранилища компонентов у нас в распоряжении имеется целая серия разнообразных методик. Рекомендуется выполнить в указанном порядке следующие действия:

1. Запустить проверку целостности системных файлов командой: sfc /scannow . Если интересуют какие-либо дополнительные подробности, то они в статье про sfc
2. Произвести восстановления хранилища компонентов:
   • для Windows 8/10+ : Восстановление хранилища компонентов при помощи DISM
   • для Windows Vista/7 : Восстановление хранилища компонентов при помощи SURT
3. Запустить утилиту SFCFix : Восстановление хранилища компонентов при помощи SFCFix
4. Провести поиск и анализ [оставшихся] ошибок в следующих файлах журналов:
   • для Windows 8/10+ : %Windir%\Logs\CBS\CBS.log (при необходимости CbsPersist_*.cab ) и %Windir%\Logs\DISM\DISM.log
   • для Windows Vista/7 : %Windir%\Logs\CBS\CBS.log (при необходимости CbsPersist_*.cab ) и %Windir%\Logs\CBS\CheckSUR.log (при необходимости CheckSUR.persist.log )
5. Если обнаружены поврежденные файлы, которые не были автоматически восстановлены утилитами предыдущих шагов, то [самостоятельно] произвести восстановление компонентов прямой заменой файлов
6. Выполнить синхронизацию оригинальных файлов с рабочими папками и пересоздание жёстких ссылок повторным запуском команды sfс /scannow

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

Выводы

В общем случае, стратегия автоматического и ручного восстановления хранилища компонентов заключается в поэтапном выявлении поврежденных зависимостей, имен отсутствующих/поврежденных файлов и их планомерном восстановлении с использованием разнообразных методик. Иногда для проведения всех этих манипуляций в ручном режиме требуется довольно существенное время, поскольку чаще всего операции приходится повторять для каждого сбойного файла. Часто в этой кропотливой работе требуются еще и довольно хорошие знания устройства компонентной модели. Отдельно стоит отметить системы, представляющие собой «кастомные» любительские сборки, поскольку на них риск убить компонентную модель многократно повышается.
Теоретически, в самом крайнем случае, восстановление хранилища компонентов можно было бы провести путем переноса (с использованием LiveCD) с работоспособной машины (имеющей аналогичную версию операционной системы) следующих частей:

1. Всех вложенных файлов/директорий в папке %WinDir%\WinSxS ;
2. Всех вложенных файлов/директорий в папке %WinDir%\Servicing ;
3. Все содержимое ветвей реестра: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing и HKEY_LOCAL_MACHINE\COMPONENTS ;

но на деле подобный глобальный поход может привести к падению системы в синий экран смерти, так что будьте предельно аккуратны!!

Источник

Очистка хранилища компонент Windows в каталоге WinSxS

Только что установленная Windows Server 2012 R2 Standard EN после установки всех обновлений, доступных в службе Windows Update занимает почти 22GB. В случае, если система готовится в качестве шаблона, с которого в дальнейшем планируется выполнять клонирование серверов, или же мы стали испытывать нехватку свободного места на системном диске уже функционирующего сервера, нам потребуется найти пути оптимизации используемого дискового пространства. Одним из возможных вариантов штатной оптимизации, заложенной в Windows Server, является операция обслуживания так называемого хранилища компонент в каталоге %windir%\WinSxS .

Перед нами показатель заполненности системного диска на только что установленном и обновлённом виртуальном сервере с ОС Windows Server 2012 R2 Standard.

Анализ текущего состояния хранилища компонент Windows и его последующую очистку мы можем провести с помощью утилиты, входящей в состав ОС – Dism.exe (сокращение от Deployment Image Servicing and Management).

Запускается анализ следующей командой (требуются права Администратора):

По окончании выполнения команды, изучим её вывод и обратим внимание на показатель «Number of Reclaimable Packages«, который определяет число пакетов, заменённых в процессе обновления системы через Windows Update. То есть, это те пакеты, которые могут быть безболезненно вычищены из хранилища.

Значение «Yes» в строке «Component Store Cleanup Recommended» говорит о том, что, по данным проведённого анализа, очистка возможна и рекомендуема.

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

Запуск процедуры очистки хранилища компонент Windows выполняется командой:

В нашем примере на только что установленной Windows Server 2012 R2 (с выполненной последующей доустановкой

200 обновлений) время выполнения процедуры очистки заняло более двух часов.

Дождавшись успешного завершения, посмотрим, как изменилась ситуация на диске.

Как видим, вместо ранее имеющейся величины свободного места в 7,43 GB, теперь мы имеем 16,6 GB, то есть операция очистки высвободила в нашем случае 9,17 GB. Результат очень даже ощутимый.

Однако в системе по-прежнему остаются файлы, которые могут использоваться для отката установленных обновлений, поддерживающих процедуру деинсталляции. Это хорошо видно, если в оснастке управления установки/удаления программ appwiz.cpl перейти в режим отображения информации об обновлениях. Здесь на большинстве обновлений мы увидим возможность удаления, то есть фактического отката заменяемых обновлениями файлов на их ранние версии.

Если мы считаем, что система работает стабильно и имеем уверенность в том, что нам не потребуется выполнять удаление каких-либо обновлений, то мы можем выполнить дополнительную процедуру удаления предыдущих версий для всех компонент, которые были изменены установленными обновлениями. Нужно понимать, что тем самым мы лишим себя возможности отката установленных обновлений. В таком случае, ранее используемую команду выполняем с дополнительной опцией /ResetBase :

Снова посмотрим, как изменилась ситуация на диске.

Как видим, на этот раз мы смогли высвободить ещё 1 GB ёмкости дискового тома.

И теперь, если мы снова заглянем в оснастку управления установки/удаления программ appwiz.cpl в режиме отображения информации об обновлениях, то увидим, что при выборе любого из обновлений кнопка Uninstall более нам недоступна.

Таким образом, если мы решили прибегнуть к описанной выше процедуре очистки хранилища компонент Windows в каталоге WinSxS, то сначала лучше использовать более щадящую команду очистки, то есть без ключа /ResetBase , так как результат такой очистки в большинстве случаев даёт нам вполне удовлетворительный размер освобождаемого места, оставляя при этом больше «шансов для манёвра» в случае проблем с уже установленными обновлениями. То есть команду очистки с ключом /ResetBase предлагается использовать только в крайних исключительных случаях.

Источник