Windows servicing packages что это за папка

«Неуловимый» список установленных обновлений Windows

Вы когда-нибудь задумывались, с помощью чего формируется список установленных обновлений Windows? А через какое API его достать? Ответы на эти и другие возникающие вопросы я постараюсь дать в своём небольшом исследовании.

Предыстория или с чего всё началось.

В нашей компании каждый год проходит конференция молодых специалистов, где каждый участник может решить проблему какого-либо отдела (список тем заранее предлагается).

Раньше на каждое «ТО» с помощью WSUS подтягивались все выпущенные обновления и распространялись на все машины. Также периодически выходили ТСБ (технические сервисные бюллетени), в которых указывалось, что требуется установить необходимые обновления в виде изолированных пакетов. В итоге у нас накапливаются обновления, которые в WSUS отследить нельзя, а можно было увидеть только через панель управления в разделе «Установленные обновления».

Бывают ситуации, когда АРМ или сервер «падает» и приходится его восстанавливать из образа, созданного некоторое время назад. При восстановлении из образа есть вероятность того, что мы можем потерять нужные нам обновления (которые пришли в виде изолированных пакетов), которые устанавливались до падения машины. Объяснил максимально подробно насколько мог, потому что уточнения будут уже коммерческой тайной.

Вот поэтому и возникла идея создать программу, которая бы могла извлечь этот список обновлений (желательно удаленно по локальной сети), записать в файл/базу, сравнить текущий перечень с неким шаблоном и выдать сообщение на SCADA систему через один из протоколов — SNMP, OPC.

Как вы могли догадаться из названия статьи, уже на выборе метода получения списка у меня возникла непростая задача. Я, как обычно, решил поискать нужное в поисковике, задал вопросы на профильных ресурсах (раз, два, на английском stackoverflow почему-то не понравился мой вопрос и его пришлось удалить), но все ответы не давали нужного результата. Поэтому пришлось разбираться самому, о чем и пойдет речь далее.

Консольные команды

Начнем с простого и воспользуемся тем, что предлагает нам Windows без использования сторонних средств. Это можно сделать с помощью следующих команд:

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

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

Все методы проверялись на чистых образах систем (Windows 7, 8, Server 2012 R2) с интегрированными обновлениями, после каждого обновления через Центр обновления с официальных серверов Microsoft проводилась дополнительная проверка. Остановимся на каждом из них подробнее.

Примечание: далее для своего удобства все результаты я буду вставлять в List. Это, возможно, не рационально, но тогда мне это казалось хорошей идеей.

Есть и вторая вариация этого метода: Update Session — получение информации с помощью подключения к сессии обновления Windows Update Agent (в данном случае работаем не напрямую с библиотекой).

Microsoft подсказывает об удаленном использовании API.

Главный минусы этих двух методов — не позволяют найти исправления KB, которые не распространяются через Центр обновления Windows. Можно увидеть только то, что прошло через сам агент обновления, то есть данный вариант нас не устраивает.

Система обслуживания образов развертывания и управления ими (Deployment Image Servicing and Management) — это средство командной строки, которое может использоваться для обслуживания образа Windows или для подготовки образа среды предустановки Windows (Windows PE). Является заменой диспетчера пакетов (Pkgmgr.exe), PEimg и Intlcfg.

Данная утилита используется для интеграции обновлений, сервис паков в образ системы. Обновления Windows представляют собой отдельные модули, которые могут быть представлены в нескольких вариантах:

Количество обновлений совпадало с количеством из списка Панели управления до первого апдейта через центр управления — после него количество обновлений стало меньше (было 214, стало 209), хотя по логике они должны были увеличиться. Примеры вывода До обновления, После обновления.

С чем это связано я могу только предполагать — возможно, какие-то обновления замещали предыдущие, следовательно, и количество стало меньше.

Чуть позже я наткнулся на утилиту от китайцев DISM++, которая основана не на DISM API или DISM Core API, но имеющиеся в ней библиотеки не имеют нужных мне открытых методов, поэтому я забросил эту идею и продолжил поиски дальше.

Windows Server Update Services (WSUS) — сервер обновлений операционных систем и продуктов Microsoft. Сервер обновлений синхронизируется с сайтом Microsoft, скачивая обновления, которые могут быть распространены внутри корпоративной локальной сети. Опять же специальный инструмент, предназначенный для работы с обновлениями.

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

Чтобы не выделять раздел жесткого диска для новой системы я пользуюсь WinNTSetup и устанавливаю систему в VHD диски — загрузчик, начиная с Windows 7 (редакций Professional/Ultimate), прекрасно справляется с загрузкой с образа диска. Полученные таким образом диски можно спокойно использовать и в Hyper-V — убиваете сразу двоих зайцев. Не забудьте только сделать заранее копию хранилища BCD через команду bcdedit /export e:bcd_backup.bcd.

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

Обязательно уделите внимание на порт, я из-за опечатки (8350 вместо 8530) не мог получить обновления на клиентских машинах, хотя сделано было всё верно. Так же названия пунктов в групповых политиках на Windows 7 и Windows 8 различаются.

Для получения отчета средствами WSUS необходимо дополнительно установить пакет — система уведомит вас об этом.

Так как интернета нет, то ситуация с обновлениями выходит как на скриншоте ниже:

Поведение похоже на WUApi — если обновления не прошли через них, то они не знают об этом. Поэтому данный метод снова не подходит.

Windows Management Instrumentation (WMI) в дословном переводе — инструментарий управления Windows.

WMI — реализованный корпорацией Майкрософт стандарт управления предприятием через Интернет для централизованного администрирования и слежения за работой различных частей компьютерной инфраструктуры под управлением платформы Windows. WMI является открытой унифицированной системой интерфейсов доступа к любым параметрам операционной системы, устройствам и приложениям, которые функционируют в ней.

Данный метод позволяет получить данные как с локальной машины, так и удаленно в пределах локальной сети. Для обращения к объектам WMI используется специфический язык запросов WMI Query Language (WQL), который является одной из разновидностей SQL. Получать список мы будем через WMI класс win32_quickfixengineering.

Количественно всё совпадает (даже после обновлений), поэтому было решено использовать этот метод. Для программного создания WMI запросов советую использовать следующую утилиту — WMI Delphi Code Creator. Благодаря ей я немного по другому взглянул на свой код и решил использовать заготовку из этой программы.

Полученные данные методом WMI меня не остановили, и я решился на „поверхностный реверс-инжиниринг“. Воспользуемся утилитой Process Monitor из сборника программ Sysinternals Suite для выявления файлов и ветвей реестра, которые используются при вызове выше перечисленных консольных команд и обращению к пункту „Установленные обновления“ через Панель управления.

Моё внимание привлек файл wuindex.xml, расположенный в папке C:WindowsservicingPackages. Для его анализа была написана следующая программа:

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

Вот мы подошли к тому, с чем связаны все эти методы. Продолжая анализ логов Process Monitor я выявил следующие папки и файлы.

Файл DataStore.edb, расположенный в папке C:WindowsSoftwareDistributionDataStore. Это база данных, в которой содержится история всех обновлений установленной версии Windows, включая те обновления, которые только стоят в очереди.

Для анализа файла DataStore.edb использовалась программа ESEDatabaseView. В БД существует таблица tbUpdates, содержимое которой трудно интерпретировать.

После мое внимание привлек процесс TiWorker.exe, который вызывался каждый раз при открытии пункта в Панели управления. Он „ходил“ по многим папкам, одна из которых вывела меня на верный путь.

C:WindowsSoftwareDistribution — это папка, используемая службой обновления Windows для загрузки обновлений на компьютер с последующей их установкой, а также хранит сведения обо всех ранее установленных обновлениях.

Папка WinSxS, расположенная по адресу C:Windowswinsxs. Это служебная папка операционной системы Windows служащая для хранения ранее установленных версий системных компонентов. Благодаря ее наличию существует возможность отката к более старой версии обновления в случае необходимости.

C:Windowsservicing — основная составляющая всей системы, имя которой Component-Based Servicing (CBS).

CBS — обслуживание на основе компонентов, составляющая Windows, интегрированная с службой Windows Update. В противоположность обслуживанию на основе файлов File-Based Servicing (FBS) (для ОС, предшествующих Windows Vista), в котором файлы обновлялись прямо в системных директориях, в CBS появилась целая иерархия директорий и целое семейство (стек) модулей/библиотек обслуживания.

CbsApi.dll — основная библиотека поддержки технологии CBS. Не имеет открытых методов, поэтому напрямую использовать её я не смог. Microsoft использует TrustedInstaller.exe и TiWorker.exe для доступа к методам данной библиотеки и уже через эти процессы выводит нужные нам данные. ‪Записи ведутся в C:WindowsLogsCBSCBS.log.

На момент создания прототипа программы (на скриншотах можете увидеть май 2019) русскоязычной информации о CBS не было, но в конце августа нашлась очень хорошая статья в блоге — http://datadump.ru/component-based-servicing. Очень интересная статья, которая подтвердила мой опыт и собрала в себе нужную информацию. И ещё по теме: http://www.outsidethebox.ms/17988/

Вывод

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

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

Источник

Windows servicing packages что это за папка

AppDataLocalPackages что это за папка в Windows 10?

AppDataLocalPackages — папка, которая возможно используется для работы метро-приложений. То есть не обычные программы, там Хром, Офис, Блокнот, а именно метро-приложения, которые запускаются из меню Пуск и которые еще можно назвать плиточными. Если вы собрались очистить папку Packages, то будьте готовы к глюкам с этими метро-приложениями.

Юзеры в сети пишут — папка AppDataLocalPackages много весит, оказывается, что в этой папке могут быть всякие непонятные.. папки.. файлы.. но среди этого всего возможно что есть папка кэша — cache. И вероятно что именно она и может прилично занимать места. У одного юзера так и было — в Packages внутри была папка AVG Web TuneUp, а в ней — cache, которая и весила десятки гигабайт.

То есть уже делаем вывод — просто так взять и удалить AppDataLocalPackages нельзя. Почистить — можно попробовать. Не исключено что в чистилке CCleaner уже учтено то, что может быть такая папка Packages, которой можно почистить файлы кэша.

Может стоит удалить некоторые метро-приложения, но гарантирует ли это и удаление кэша этих приложений?

Один юзер пишет — у него начало пропадать место на системном диске. Начал смотреть. Оказалось папка Packages. Но он узнал кто виновник — приложение Microsoft.BingNews. Юзер уточнил — новости читает часто и один визит, предположительно, сьедает около 50 мегов на диске. Господа, это абсурд. Мне кажется что обычный браузер вроде Хрома и то так не беспредельничает. Юзер папку очистил, но как — непонятно.

У меня этой папки нет. Но есть предположение, что в папке Packages могут быть файлы или папки, которые в своем названии как-то намекают к какому приложению они имеют отношение. Например я нашел такие пути:

konstantin — это просто имя учетной записи. Пользователя так звали видимо. Так вот — есть папка C6965DD5.VK_v422avzh127ra, по на названию папка и ее содержимое вроде как имеет отношение к приложению ВКонтакте. В теории остальные папки также могут иметь подсказки в названиях к чему они относятся. Если в папке приложения есть LocalCache и она много занимает места — переименуйте ее в LocalCache_temp и посмотрите, если не будет проблем вообще, значит можно удалять. Наблюдать советую день-два.

И снова я натыкаюсь на комментарий чела — он пишет что нельзя удалять папку Packages иначе будут удалены метро-приложения. Даже после удаления папка будет восстановлена. Но с другой стороны — сами приложения никак не могут весить десятки гигов. Это какие-то другие данные, в большой вероятностью что временные, которые можно удалить. Как я уже писал выше — скорее всего это кэш приложений (нужно разбираться и смотреть в папке Packages).

Так, а почему вы вам не поэкспериментировать? Удалять Packages — нет, не нужно. Зайдите в эту папку и переименуйте то, что кажется можно будет удалить. То есть папки кэша или просто те, которые оч много весят. Будут ли проблемы? Да, могут. Что делать? Все просто — нужно создать точку восстановления. Зажмите Win + R, далее укажите команду:

control /name microsoft.system

В свойствах выбираете системный диск и нажимаете Создать:

Указываете имя точки и создаете:

После создания точки можете попробовать удалить какие-то тяжелые папки в Packages.

Выяснилось, что удаление папок в Packages может быть проблемным из-за отсутствие прав. Просто будет выкидывать ошибку. Что делать? Есть выход — использование утилиты Unlocker. Она создана спецом для удаления неудаляемых файлов и папок. Бесплатная, я пользуюсь версией 1.9.2. Если будете устанавливать — осторожно, при установке хочет установится какой-то Дельта Тулбар, поэтому внимательно смотрите и снимите необходимые галочки.

Удивительно, но мне удалось найти команду очистки кэша папки AppDataLocalPackages, о такой команде даже и не слышал:

Зажмите кнопки Win + Q и вставьте эту команду потом выберите в результате о очистите кэш.

Еще одно небольшой открытие — оказывается в антивирусе Касперский есть функция очистки папки Packages.

Уже второй юзер пишет — AVG TuneUp может быть причиной большого веса папки.

Ребята, снова важная информация. Один пользователь на форуме Microsoft говорит следующее: если вы удалили все метро-приложения при помощи PowerShell или вообще не пользуетесь метро-приложения, тогда вы можете безопасно удалить папку Packages. Из чего делаем вывод — папка нужна только для метро-приложений. То есть на обычные программы и на работу системы папка влияния не оказывает.

Один юзер тоже очистил папку Packages и причиной было приложение AVG Web TuneUp. Я заинтересовался, узнал:

На этом все. Искренне надеюсь информация помогла. Удачи.

Windows servicing packages что это за папка

Куда девается свободное место в службах удаленных рабочих столов

Описываю классическую ситуацию. Есть RDS ферма, которая состоит из двух посредников (RD Connection Broker) и 15-20 хостов RDSH, к котором непосредственно подключаются удаленные пользователи. В большинстве случаев, пользователи имеют перемещаемые профили. Все хорошо, все работает, но случается момент, что появляется еще пара сотен юзеров, например, из-за расширения компании или поглощения другой, это не важно. На ваших узлах, становится катастрофически не хватать свободного места. Если у вас виртуальные машины, то тут проще можно расширить ресурсы, при наличии места на датасторах, в случае с физическими серверами сложнее, так как расширять существующие RAID массивы, очень геморройная вещь, да и места на СХД, может так же не хватать. Да и расширять до бесконечности вы не можете. Плюс за счет того, что профили перемещаемые, то вы должны умножить новое дисковое пространство на количество ваших узлов, вот такая математика.

Установка WinDirStat, очень тривиальная, я не буду ее приводить. После инсталляции запускаем утилиту. На первом экране WinDirStat, попросит вас выбрать локальный диск или каталог для сканирования файлов. В моем примере на Remote Desktop Session Host хосте, один диск C:, его я и выбирая.

У вас начнется сканирование вашего локального диска, на предмет того, чем он занят. Вы увидите забавных пакменов.

Как видим, у меня самым объемным является папка Users, второй папка Windows 45 ГБ. С правой стороны вы увидите столбец по форматам, там сразу можно выделить MP4 или MSI, видно сколько они занимают. Ниже разноцветные квадраты, это так выглядят все типы файлов на жестком диске в этой утилите.

Открыв папку профили, вы сразу видите самые объемные из них, смотрите, чем они заняты и проводите зачистку, с визгами и орами от пользователей. Но тут никак больше.

Очистка папки Windows от мусора

Далее мы посмотрим, почему папка Windows занимает 45 ГБ, что очень странно. Открыв более подробное описание, мы с вами видим, что 70% папки Windows на моем хосте RDS фермы, занимают три папки:

Что такое и как очистить папку Installer

Как видите у меня папка Windows Installer занимает много места, это аж 15 ГБ. Если открыть ее содержимое, то вы увидите GUID номера, ваших программ.

Если более детально капнуть в папку Windows Installer, то тут в основном лежат файлы msp, это пакеты обновления, MSI и MST файлы.

Хочу отметить, что папка Installer, по умолчанию скрыта, и для ее отображения, вы должны включить скрытые файлы и папки в Windows.

Можно ли удалить папку Windows Installer?

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

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

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

Как правильно очистить папку windows installer

Перед всеми нашими манипуляциями, вы должны обязательно выполнить вот что:

Для того, чтобы правильно очистить каталог C:WindowsInstaller, можно воспользоваться бесплатной утилитой PatchCleaner.

Как работает PatchCleaner. Операционная система Windows содержит список текущих установщиков и патчей, к которым можно получить доступ через вызовы WMI ( Инструментарий управления Windows ). PatchCleaner получает этот список известных файлов msi/msp и сравнивает их со всеми файлами msi/msp, которые находятся в каталоге c:WindowsInstaller. Все, что находится в папке, но не в списке, представленном окнами, считается сиротскими файлами и помечено для перемещения или удаления.

Принимаем лицензионное соглашение «I Agree»

Указываем для каких пользователей будет устанавливаться PatchCleaner.

Установка PatchCleaner завершена, запускаем ее.

После запуска, утилита проведет сканирование. У вас будет два показателя:

По пути Move Loction, будет делаться резервная копия, на всякий случай, можете при желании изменить данный путь.

Нажав на кнопку «details», вы увидите более подробный список, устаревших пакетов msp, прочитать к каким программам, они относились.

Чтобы запустить процесс освобождения дискового пространства на ферме RDS и уменьшить размер папки C:WindowsInstaller, нажмите кнопку «Move».

Вас спросят, хотите ли вы этого, нажимаем yes

Все уменьшение папки Installer выполнено.

Видим, что больше в системе нет устаревших файлов.

В папке с резервной копией, теперь лежат ваши устаревшие файлы.

Если вы не хотите производить чистку Windows Installer, или просто боитесь это делать, но располагаете в системе другим, дополнительным диском, на котором есть свободное место, то можете перенести C:WindowsInstaller на него, для этого можно воспользоваться символическими ссылками, мы их уже использовали когда переносили OST файл в Outlook.

Предположим у меня есть еще диск E:, и на нем есть 100 гб свободного места и я бы хотел на него перенести системную папку, для этого открываем командную строку с правами администратора и вводим команду, но перед этим ОБЯЗАТЕЛЬНО, скопируйте C:WindowsInstaller в E:Installer.

Теперь если вы зайдете в каталог C:WindowsInstaller, то увидите на папке стрелочку в левом углу, это означает, что это символическая ссылка, ведущая в другое место. Надеюсь с папкой Installer мы разобрались, и очистили часть места на RDS ферме.

Что такое и как очистить папку ServiceProfiles

Я нашел ответ от разработчика Windows, что делал эту службу кэширования, его зовутNiklas Borson, вот что он отвечал, на вопрос, почему на RDS ферме, папка ServiceProfiles имеет большой размер.

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

В свою очередь, вы можете сделать bat файл вот с таким содержимым, и удалять файлы старше 30 дней из папки ServiceProfiles. Скрипт останавливает две службы:

net stop FontCache && net stop FontCache3.0.0.0

net start FontCache && net start FontCache3.0.0.0

Что такое и как очистить папку WinSxS

Очистка папки WinSxS в Windows 10, 8 и Windows 7

Продолжаем с вами производить очистку в папке Windows, от всевозможного хлама, и на очереди у нас с вами папка WinSXS, выше я написал, что из себя представляет данная папка. Как видите утилита WinDirStat, показывает что WinSxS, занимает 7,2 гб, для этой папки, это размер в пределах нормы, но если вы у себя видите, здесь 10-15 гб и более, то это повод задуматься над ее очисткой.

Есть распространенный миф о гигантских размерах этой папки, что на самом деле не совсем так. Дело в том, что подавляющее большинство содержимого папки WinSxS является «жесткими ссылками», а Проводник и файловые менеджеры это не учитывают. Реальный вес этой папки гораздо меньше, чем пишется в ее свойствах.

Можно ли удалить папку winsxs

Саму папку удалять конечно же не стоит, а вот правильно ее почистить, это правильное решение. Ранее я вам рассказывал про встроенную утилиту в Windows, под названием cleanmgr (Очистка диска). Там запустив утилиту у вас появлялся мастер «Параметры чистки диска», в котором, чтобы была произведена очистка папки winsxs, нужно было выбрать пункт «Очистка обновлений Windows».

Если вы любите все делать из консоли, то вот вам пример очистки папки WinSxS в Windows 10. Запускаем командную строку от имени администратора и вводим команду:

Папка хранилища компонентов будет проанализирована и вы увидите сообщение о необходимости ее очистки, вы увидите ее размер.

Для операционной системы Windows 8.1 или Windows Server 2012 R2, подойдет команда:

Автоматическая очистка резервных копий обновлений в WinSxS

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

Папка WinSxS — зачем она нужна и можно ли ее удалить?

Содержание

Содержание

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

Что это за папка и для чего она нужна

WinSxS — служебная папка, которая появилась еще в Windows Vista, и присутствует во всех последующих версиях операционной системы. Полный путь к папке: C:WindowsWinSxS. Увидеть ее можно, если включить отображение скрытых файлов и папок в параметрах папок (вкладка «Вид»).

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

Учитывая специфику каталога, со временем он будет интенсивно расширяться.

Сколько места может занимать содержимое папки WinSxS

Обновления приходят регулярно, тем более сам пользователь часто вносит различные изменения в работу операционной системы. Если оптимизация каталога ранее не проводилась, или же процедура выполнялась давно, то размер папки легко может превысить отметки в 20 ГБ, но здесь есть один нюанс.

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

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

Если папка WinSxS занимает свыше 10 ГБ памяти, то чистка практически наверняка нужна.

С другой стороны, освободить место можно и при более скромных объемах.

Можно ли удалить папку WinSxS или ее содержимое?

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

Другие возможные последствия удаления отдельных файлов папки WinSxS:

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

Как очистить папку WinSxS: способы и инструкции

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

Встроенное средство очистки дисков в Windows

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

Инструкция по использованию встроенного средства очистки дисков в Windows.

Если каталог WinSxS ранее не чистился или чистился давно, то при помощи данного метода получится освободить от нескольких сотен мегабайт до пары гигабайт места.

Этот метод актуален для ОС Windows 8.1 и Windows 10. В Windows 7 данной опции изначально нет, но она появится при установке пакета обновлений KB2852386.

Утилита DISM.exe

Этот метод предполагает использование консоли. Его эффективность выше, и в результате можно освободить больше места.

Инструкция по использованию утилиты DISM.exe для очистки папки WinSxS.

Но это еще не все, что можно сделать при помощи утилиты DISM.exe. Другие полезные действия перечислены ниже.

Теперь можно полюбоваться результатом, еще раз вызвав команду Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore и сравнив результат с первым анализом. Кстати, данная команда не поддерживается в Windows 7.

В приведенном примере результат незначительный, что объясняется недавней глубокой чисткой системы, но он все-таки есть.

Планировщик задач

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

Чтобы очистить папку WinSxS при помощи планировщика задач, нужно выполнить следующий порядок действий.

Преимущество метода в том, что пользователь может настроить автоматическую очистку папки WinSxS по расписанию и забыть о проблеме. Для этого нужно кликнуть правой клавишей мыши на задаче «StartComponentCleanup», выбрав пункт «Свойства», вкладку «Триггеры», а здесь настроить расписание процедуры.

Удаление неиспользуемых компонентов

Этот метод предназначен для продвинутых пользователей. Удаление компонентов может повлиять на стабильность работы системы.

В этом случае мы будем очищать неактивные компоненты. В будущем, при необходимости, их возможно восстановить.

Посмотреть активные и неактивные компоненты Windows можно в разделе «Программы и компоненты», который находится по здесь: Панель управленияПрограммыПрограммы и компоненты. Интересующий пункт находится в левой части окна.

Наиболее популярными вариантами очистки директории являются первые два метода, о которых снято много видеороликов для YouTube.

Воспользовавшись предложенными в статье способами, можно уменьшить размер WinSxS. Результат зависит от выбранного способа и того, как часто пользователь выполняет очистку системы от мусора. Как правило, интерес к папке WinSxS возникает при необходимости освобождения места на системном диске. А том, как это сделать можно прочитать здесь.

Источник

Наверняка уже ни для кого не секрет, что как и в любом (без исключения) программном обеспечении, в коде операционных систем присутствуют ошибки. Периодически тем или иным образом их удается обнаружить, о чем рано или поздно узнает разработчик, в чьих интересах производить оперативное устранение найденных проблем. Но мало выпустить исправление (заплатку/патч), изменения эти требуется еще как-то доставить до пользовательских операционных систем, функционирующих по всему миру. Помимо ошибок, на всем протяжении цикла поддержки операционной системы, в неё добавляются и новые функциональные возможности. Все перечисленные виды вносимых в систему изменений (исправления, обновления, дополнения) на данный момент принято обобщать в огромный комплекс задач под названием обслуживание операционной системы.
С появлением и развитием сети Интернет, методы доставки контента обслуживания до географически-удаленных операционных систем претерпели существенные изменения: сперва в виде доступных на сайте Microsoft для скачивания файлов, затем, по мере развития архитектуры операционных систем и, в частности, алгоритмов обновления, трансформировались в сложные многоуровневые сервисы, производящие автоматическую загрузку и обновление. В последнее время Microsoft запустила уже непрерывный цикл обновлений настольных операционных систем, который подразумевает под собой не только (отдельные) текущие обновления, но так же и глобальные доработки, приводящие к (прозрачному) переходу к следующим редакциям ОС.

Тем не менее вопрос, касающийся механизмов обновления является темой несколько иной статьи, а в этом материале мы, пожалуй, начнем с краткого экскурса в историю обслуживания операционных систем корпорации Microsoft. Сразу хочу оговориться, что никаких глубоких специфических данных тут пока что не будет, просто необходимые вводные сведения по достаточно значимой технологии под названием Обслуживание на основе компонентов, в которой многое до сих пор для меня не ясно. Итак, на протяжении развития операционных систем Windows существовало несколько основных видов обслуживания:

Обслуживание на основе файлов

В операционных системах, предшествующих Windows Vista (Windows XP и ранее), применялся метод обслуживания, носящий название обслуживание на основе файлов (File-Based Servicing, FBS). Процесс обслуживания был организован достаточно незатейливо: на основе .inf-файла описания изменений, обновляемые системные файлы перезаписывались новыми версиями непосредственно по пути основного размещения (в основном это: %WinDir%System32), при этом копия свежей версии помещалась еще и в кеш защищенных системных файлов (%WinDir%System32DLLcache). Если в момент обновления задействованные системные файлы кем-то использовались (были заняты/заблокированы), то замена их производилась позже, на этапе очередной загрузки операционной системы простым копированием уже новой версии из директории кеша в директорию основного размещения. А как же старые версии, спросите вы? А старые версии обновляемых библиотек удалялись безвозвратно, но в некоторых случаях (с включенной опцией rollback) их все же можно было сохранять в системе (в каталогах вида %WinDir%$NTUninstallKBxxxxxxxx$). Эта особенность создавала проблему совместимости и позже, для её решения был добавлен каталог WinSxS, в который сохранялись старые (предыдущие) версии некоторых библиотек для совместимости с Windows95-приложениями. Как вы видите, механизм обслуживания на основе файлов был довольно прост, поэтому с него и начали, тем не менее он имел существенные недостатки:

• Основная проблема: обновление единственных экземпляров системных файлов (библиотек), что неизменно вело к сбоям в работе приложений, оптимизированных (их авторами) на использование определенной версии общих DLL. Данная категория проблем получила название проблем совместимости библиотек и исполняемых модулей.
• Обновления (update) или исправления (hotfix) содержали полноценный инсталлятор (исполняемые модули с именами update.exe/hotfix.exe), который непосредственно производил обновление файлов (библиотек) в системе. Сами понимаете, что подобная избыточность делала каждое обновление фактически автономным пакетом [установки], что вело к отсутствию унификации/контроля установки.
• Все файлы были как бы «свалены в кучу», то есть размещались в общей для всех директории.
• В системе отсутствовал менеджер пакетов, что делало контроль за процессом обновления менее гибким, не было единой базы установленных компонентов, невозможно было контролировать и производить возврат к предыдущему состоянию («откат») и прочие, ставшие уже привычными для других операционных систем, виды обслуживания.

Очевидно, что назревало решение по интеграции в линейку операционных систем Windows собственной подсистемы управления пакетами.

Обслуживание на основе компонентов

Начиная с Windows Vista была разработана и внедрена принципиально новая модель обслуживания, которая получила название обслуживание на основе компонентов (Component-Based Servicing, CBS). В противоположность обслуживанию на основе файлов, в котором файлы обновлялись прямо в системных директориях, в CBS появилась аж целая иерархия директорий и целое семейство (стек) модулей/библиотек обслуживания. Было введено понятие компонента, представляющего собой (небольшой) набор файлов, сгруппированных по назначению, функциональности и возможности многократного использования (активации/деактивации). В компонент входили: библиотеки/исполняемые, манифесты, каталог безопасности и некоторые другие. Появились статусы компонентов/обновлений, в связи с чем появилась возможность активировать или отключить различные возможности (features) в операционной системе по мере необходимости. Статус означает, что сам по себе компонент может быть установлен в ОС, но не активирован. Это вводит понятие состояния, которое помимо компонентов так же затрагивает обновления и исправления. Характерный пример — средство удаленного администрирования сервера (RSAT) в Windows 7, при инсталляции которого устанавливаются все компоненты средства администрирования, но ни один из установленных элементов не активен после инсталляции. Все что делает установщик в данном случае, так это просто добавляет компоненты в систему, а вот позже необходимо самостоятельно задействовать оснастку Программы и компоненты (или действовать через dism) для включения требуемых возможностей.
Как вы уже поняли, обслуживание на основе компонентов (компонентная модель) в очередной раз перевернуло все с ног на голову и принесло множество «счастливых» моментов в жизнь простого технического специалиста, существенно изменив сложившийся годами привычный подход к принципам обслуживания операционной системы.

Фактически обслуживание на основе компонентов представляет собой первый полноценный пакетный менеджер для Windows (УРА!). Он обладает внушительным функционалом: ведет историю перезаписанных файлов, может удалить один пакет, если некоторые его файлы перезаписаны другим пакетом, хранит все версии файлов в хранилище компонентов, интегрирован со службой обновления Windows (Windows Update), что обеспечивает обновление всех установленных пакетов.

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

1. обеспечивает полный цикл сопровождения (установка/удаление/предоставление/восстановление) всех версий общих модулей/библиотек.
2. является более надежным (стабильным) и безопасным механизмом, в отличии от автономных инсталляторов (update.exe/hotfix.exe), хорошо знакомых по предшествующим версиям операционной системы Windows.
3. обеспечивает более управляемый (контролируемый) процесс установки, позволяющий добавлять обновления, драйверы и дополнительные компоненты, решая проблемы нестабильности, вызванные неправильной/частичной установкой.
4. позволяет упаковывать любые компоненты и возможности в виде небольших модулей, которые обеспечивают весь функционал компонента.
5. обеспечивает хранение множества версий объектов (файлов) при помощи механизма WinSxS (Side-by-side assemblies);
6. извечная проблема Windows – отсутствие на протяжении очень продолжительного времени собственной системы управления пакетами (менеджера пакетов), наконец-то решена, встречайте CBS!

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

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

• Включение/отключение компонентов Windows (оснастка Программы и компоненты — Включение и отключение компонентов Windows);
• Управление ролями посредством оснастки Server Manager в серверных версиях ОС;
• Восстановление работоспособности системы после сбоев и разнообразных проблем загрузки;
• Удаление/установка (проблемных) обновлений;
• Поддержка функционирования приложений, использующих технологию Бок-о-бок (Side-by-Side);
• Использование Центром обновления Windows при установке новых компонентов;
• Перенос системы между различными редакциями Windows;

Хранилище компонентов (и пакетов)

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

1. Хранилище компонентов;
2. Хранилище пакетов;

Файловая система

А поскольку единственный механизм для постоянного хранения данных — это (любой) носитель информации и размещаемая на нем файловая система, то в контексте компонентной модели была создана иерархия каталогов под названием хранилище компонентов (каталог компонентов), располагающееся в дереве директорий с корнем в %WinDir%WinSxS (традиционно: C:WindowsWinSxS). Разработчики уверяют что папка WinSxS является хранилищем разных версий общих библиотек и представляет собой «установочное и обслуживаемое состояние» всех системных компонентов.

Хранилище компонентов — иерархия директорий, в которой размещаются все версии всех установленных в системе компонентов.

Именование каталога WinSxS выбрано не случайно, оно является акронимом названия Side-by-Side (Бок о бок), которое подразумевает одновременное существование в системе множества версий определенной библиотеки.

Вся суть механизма Side-by-Side (SxS) сводится к тому, что приложение может явно указать, с какой версией библиотеки оно желает работать.

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

amd64_microsoft.windows.c..-controls.resources_6595b64144ccf1df_6.0.7600.16385_tr-tr_9e98e8587a93bcd6

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

Реестр

По факту данные реестра тоже хранятся в виде файлов, тем не менее все же принято выделять его в самостоятельную сущность. Хранилище компонентов имеет часть конфигурации в реестре, в следующих ключах:

• HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionComponent Based Servicing;
• HKEY_LOCAL_MACHINESchema;
• HKEY_LOCAL_MACHINECOMPONENTS — временный, подключаемый на время обслуживания, ключ реестра. Импортируется из файла C:Windowssystem32configCOMPONENTS;

соответственно, в ключе HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionComponent Based ServicingPackages перечисляются все установленные в системе пакеты.

Для того, что бы была возможность работать со списком пакетов, необходимо назначить правильные права на весь раздел Component Based Services со всем вложенным содержимым (подразделами → подключами). Как можно увидеть по снимку экрана, у каждого пакета имеется параметр с именем Visibility, который ответственен за видимость пользовательскими утилитами обслуживания, и если он имеет значение 1 — пакет виден, если 2 — то это скрытый пакет. У пакета может иметься подключ Owners, в котором (в качестве параметров) перечислены родительские пакеты, в этом случае отдельно удалить сам пакет не представляется возможным. Если вы самостоятельно проинспектируете подключ Owners, то увидите, что значительная часть системных пакетов входит в состав неких родительских глобальных пакетов с именами вроде Microsoft-Windows-EnterpriseEdition~*, Microsoft-Windows-HomeBasicEdition~*, Microsoft-Windows-HomePremiumEdition~*, Microsoft-Windows-ProfessionalEdition~*, Microsoft-Windows-StarterEdition~*, Microsoft-Windows-UltimateEdition~*. Соответственно, чтобы иметь возможность удалить пакет, его нужно исключить из всех родительских пакетов (сделать автономным), попросту удалив находящиеся в подключе Owners параметры.

Компоненты (Components)

Самое время рассмотреть компонент повнимательнее:

Компонент (Component) — группа файлов, в которую включены: один (или несколько) бинарных файлов, .cat-файл каталога безопасности и .manifest-файл (файл формата XML с описанием настроек безопасности, метода инсталляции и параметров реестра).

Упрощенно компоненты состоят из полезной нагрузки (библиотеки, исполняемые файлы, локальные файлы конфигурации и прочие файлы) и манифеста (определяет зависимости). Каждый такой набор содержит все необходимые файлы, параметры реестра, и методы, требуемые для полной установки/удаления компонента. В компонентной модели атомарной единицей при обновлении является не файл (как ранее при файловом методе обслуживания), а компонент, и при обновлении единственного файла выпускается новая версия всего компонента, в состав которого входит обновляемый (пропатчеваемый) файл. Таким образом:

Компонент это минимальная установочная, неделимая единица компонентной модели.

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

При этом большинство файлов, «располагающихся» (отображаемых) в системной директории %WinDir%System32 (и дереве подкаталогов), представляют собой текущие версии системных модулей/библиотек, и на уровне файловой системы являются жесткими ссылками, связанными с оригиналами в хранилище компонентов (%WinDir%WinSxS).

Компоненты группируются по пакетам, но у большинства пакетов компонентов нет.

Все отключаемые компоненты, видимые в оснастке Удаление компонентов Windows, можно получить командой:

dism /Online /Get-Features

Различные версии компонентов носят название сборок — экземпляров определенной версии компонента, которые формируются при обновлении данного компонента. Концепция компонентной модели заключается в тиражировании компонентов (общих сборок). Сборки бывают приватными и общими.

Возможность (feature)

В русскоязычной версии Windows раздел Feature почему-то представлен переводчиками интерфейса как Компонент. Интересно, но разве дословно Feature переводится не как Возможность, в то время как компонент имеет соответствие в виде Component? Казалось бы мелочь, тем не менее эта неточность порождает неразбериху в терминологии относительно разницы компонентов и возможностей. Мало того, что пользователь (да и специалист) путается во всех этих нововведениях компонентной модели, так тут еще происходит откровенная подмена понятий. К примеру, хорошо знакомая всем оснастка Programs and Features выглядит в русской версии как Программы и компоненты. Если мы откроем её, то увидим, что с её помощью мы можем:

• Удалять установленные в системе программы;
• Включать/отключать компоненты операционной системы;

Вроде все привычно, не так ли? Тем не менее, если мы открываем оснастку Включение или отключение компонентов Windows мы видим там модули вроде «Internet Explorer 11», «Microsoft .NET Framework 3.5.1» и некоторые другие. Как вы думаете, являются все эти программы компонентами, то есть в классическом понимании атомарными неделимыми установочными единицами компонентной модели? Очевидно что нет, поскольку под компонентами в Windows подразумеваются значительно более низкоуровневые сущности, например в том же Internet Explorer 11 более 20 компонентов. Так что же это тогда такое? Давайте разбираться.

Любой программный продукт состоит из компонентов (components), сгруппированных в возможности (features). Соответственно, Возможность (feature) — это иерархическая группа компонент (и/или других возможностей).

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

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

Пакеты (Packages)

Помимо компонентов, в системе присутствуют так называемые пакеты, которые могут представлять собой как отдельные автономные инсталляции (например: Internet Explorer Optional Package, Remote Desktop Service WinIP и тому подобные), содержащие системные приложения, так и исправления операционной системы (которые отдельно могут поставляться в виде KBnnnnnnn) и комплекты драйверов.
Пакеты, по аналогии с компонентами, имеют собственное хранилище (хранилище пакетов), которое состоит из двух основных частей:

• одна часть пакета располагается в хранилище пакетов, то есть дереве директорий с корнем в %WinDir%servicingPackages. В нем содержатся конфигурационные файлы пакета, тут каждый установленный пакет/обновление представлен двумя файлами: файлом каталога безопасности (.cat) и манифеста (.mum), определяется собственным уникальным именем, которое включает в себя архитектуру процессора, имя пакета, уникальный идентификатор, версию пакета, язык локализации, для которых он был собран.
• другая часть (основные файлы) пакета размещается в хранилище компонентов, директории %WinDir%WinSxS.

Манифест пакета описывает полезную нагрузку и статус: установлен и задействован (активирован), установлен, не установлен. Статусы пакетов:

• Installed (Установлен) — пакет установлен и присутствует в каталоге WinSxS. Полезная нагрузка пакета спроецирована в файловой системе и активна;
• Superseded (Заменён) — пакет представляет собой полную замену более ранней версии пакета(ов);
• Not Present (Отсутствует) — ?;
• Staged (Промежуточное, подготовленное) — пакет не установлен, однако присутствует в каталоге WinSxS. В этом состоянии находятся многие роли/возможности в системе (сразу после установки). Когда какая-либо роль/возможность не активна, она находится как раз в промежуточном состоянии. В графическом интерфейсе состояние видно в качестве флажка напротив роли, который не активен (не установлен). Активация чекбокса компонента запускает процесс перемещения его бинарных файлов из промежуточного состояния в установленное;
• Absent (Отсутствует) — пакет не установлен и отсутствует в каталоге WinSxS. Иногда это означает, что пакет «отключен и его полезная нагрузка удалена»;

Соответственно, в процессе установки пакеты выполняют обновление (имеют своей целью) компонентов. В компонентной модели каждый пакет может содержать одну или несколько отключаемых возможностей (в виде опций). В общем случае пакеты бывают установленными и подготовленными (к установке). Все установленные и видимые в системе пакеты можно получить командой:

dism /Online /Get-Packages

Обновление (KBnnnnnnn)

Не знаю, правильно ли выделять обновления в отдельную категорию, или нет? Обновления представляют собой пакеты, упакованные в виде отдельных модулей (фактически обновление содержит пакеты). Могут быть представлены в нескольких вариантах:

• .cab-файлы (Cabinet) — архивы. Предназначены для распространения и установки при помощи модулей Центра обновлений Windows в автоматизированном режиме. В архиве (наряду с другими файлами) содержатся двоичные данные для обновления системных файлов. Они могут быть в неупакованном (нормальном) виде, либо в упакованном (тип PA30). Так же, эти двоичные данные могут быть в виде файлов для непосредственной полной замены или в виде бинарных патчей (через MSDelta/PatchAPI);
• .msu-файлы (Microsoft Update Standalone Package) — исполняемые файлы. Предназначены для распространения и установки самими пользователями в ручном режиме через каталог обновлений Microsoft. Фактически представляют собой упакованный набор, состоящий из .cab-, .xml, .txt-файлов;

Манифесты (Manifests)

С манифестами у многих возникает постоянная путаница, поскольку по задумке разработчиков они обеспечивают выполнение сразу целого ряда задач. Но надо помнить, что:

Манифест — блок XML-данных, описывающий (и определяющий) общие/частные сборки, с которыми приложение (сборка) связано во время выполнения. Что-то вроде личного паспорта приложения.

Манифест хранит следующие данные:

• Информация о сборке: имя, версия, контрольная сумма, открытый криптографический ключ.
• Список имен файлов, входящих в сборку (в случае если она является многофайловой).
• Список зависимостей: перечисление сборок, необходимых для функционирования данной [сборки].
• Связи типов (экспортируемых сборкой) с их внутренней реализацией.

Фактически манифест является паспортом приложения. Тем не менее можно дать условное псевдоделение типов манифестов применительно к хранилищу компонентов и пакетов:

• Манифест компонента (файл с расширением .manifest) – паспорт компонента Windows. Манифест компонента задает его зависимости от имен, версий, ресурсов и других компонентов, в нем указываются различные параметры компонента, такие как наименование, каталог установки, параметры (ключи) реестра, исполняемые файлы, наименования служб и прочие. Манифест определяет как именно файлы группируются по компонентам. Имя файла манифеста включает имя соответствующей сборки, размещаемой в каталоге %WinDir%WinSxS. Размещается в каталоге %WinDir%WinSxSManifests;
• Манифест пакета или обновления (файл с расширением .mum) — паспорт пакета/обновления Windows. В нем указываются различные параметры пакета: наименование, идентификатор, язык установки, зависимости. Этот типа манифеста используется в качестве идентификатора (символического имени) сервиса обслуживания, для выполнения над пакетом операций включения/отключения/удаления посредством различных сервисных утилит (DISM, pkgmgr). Имя файла манифеста включает имя соответствующего пакета, размещаемого в каталоге %WinDir%WinSxS. Размещается в каталоге %WinDir%servicingPackages;
• Манифест приложения (файл с именем основного приложения, двойным расширением .exe.manifest, или секция ресурсов с именем Manifest) — паспорт приложения Windows. В нем определены зависимости, которые приложение использует и связывает его со строго определенной версией компонента (сборки), библиотеки. Желающие использовать строго определенные версии библиотек, должны непосредственно указывать идентификаторы сборок в собственном манифесте.

Обслуживание

Обслуживание — действие в операционной системе по включению/выключению ролей/возможностей, установке/удалению обновлений и сервис-паков.

Стек обслуживания в операционных системах Windows Vista и новее состоит из трех основных уровней:

1. Верхний: работают такие клиенты как: Windows Update, Programs and Features, и MSI, которые доставляют пакеты в систему. Программные клиенты верхнего уровня в дополнение отвечают за взаимодействие с пользователем, обеспечивают сбор/хранение пользовательских настроек на всем протяжении обслуживания.
2. Средний: На среднем уровне стека обслуживания функционирует Trusted Installer (trustedinstaller.exe), CBS. Клиенты верхнего уровня спускают скачанные пакеты к CBS, которая оценивает каждый пакет для определения, применимы ли они к данной операционной системе. Для применяемых обновлений CBS предоставляет компоненты CSI, генерирует соответствующие события установки и регистрирует пакеты в оснастке Программы и компоненты, в случае необходимости. Наконец, CBS предоставляет интерфейсы для индексации и инвентаризации обновлений.
3. Нижний: На нижнем уровне стека обслуживания располагается CSI, которая использует Kernel Transaction Manager (KTM) для выполнения работы.

Как мы уже говорили, обслуживание системы в новых реалиях происходит уже на уровне компонентов. Файлы поддержки технологии расположены в каталоге %SystemRoot%servicing. Например, в Windows 7 в данном каталоге размещаются:

В стеке обслуживания реализован давно уже знакомый специалистам системный механизм под названием Защита Ресурсов Windows (Windows Resource Protection (WRP)), в операционных системах до Windows Vista более известный под именем Защита Файлов Windows (Windows File Protection (WFP)).

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

Сам принцип защиты критических файлов так же поменялся со времен WFP, теперь отсутствует системный процесс, который в режиме реального времени отслеживает попытки модификации критических файлов, а система ограничивает доступ к важным системным файлам при помощи списков контроля доступа (ACL/DACL), то есть WRP контролирует только определенные местоположения в операционной системе.

Поэтому, если Вы захотите поэкспериментировать с системными файлами, например, что-то отреверсить и поменять алгоритм работы, лучше скопируйте их предварительно из системных каталогов в какую-нибудь безобидную пользовательскую папку, что бы WRP до них не добралась!

Некоторые сервисные утилиты, например sfc, в своей работе активно эксплуатирует стек обслуживания и, соответственно, функции библиотеки wrpinitapi.dll, которая предоставляет поддержку функций работы с WRP. В процессе работы утилиты sfc, WRP посредством процесса TrustedInstaller.exe производит обход всех критических системных компонентов, которые важны для поддержки функционирования операционной системы. В процессе обхода файл, размещенный в системном каталоге, сравнивается с эталонным файлом, размещенным в хранилище %WinDir%WinSxS. Если обнаруживаются какие-либо модификации системного файла, WRP восстанавливает оригинальную копию данного файла из директории %WinDir%WinSxSBackup, которая содержит эталоны всех защищаемых системных файлов.

CSI

Поскольку слой CSI является самым низкоуровневым в компонентной модели, он то и ответственен за фактическую инсталляцию компонентов в систему. Для инсталляции компонентов CSI активно использует хранилище компонентов. Когда добавляется новый компонент, CSI помещает его в хранилище компонентов, и определяет статус, который должен получить компонент. Назначение статуса (стадии) определяет текущее состояние пакета в хранилище компонентов. В процессе установки пакета происходит изменение промежуточных состояний пакета:

• Составить список файлов, отсутствующих в пакете. Для устанавливаемого файла, первое стадия должна быть промежуточной (staged). Некоторые из этих файлов могут уже присутствовать в хранилище компонентов, отсутствующие же требуется скачать с установочного носителя или же загрузить по Сети.
• Определить какие из файлов необходимы для установки пакета и определить файлы других пакетов, которые так же могут потребоваться во время инсталляции.
• Разрешить найденные зависимости и быть уверенным что все необходимые файлы присутствуют перед началом процесса установки.
• Выполнить установку.

Когда пакет удаляется, процесс реверсируется:

• Инсталлятор создает список всех используемых файлов, и другие действия которые необходимы для перезагрузки ОС.
• Удалить файлы или зависимости – файлы могут быть удалены из системы или могут остаться в хранилище компонентов для будущего использования.
• Неиспользуемые файлы могут быть удалены из системы, затем система может быть перезагружена для выполнения освобождения места и удаления файлов, которые были заняты (использовались) на предыдущих шагах.

Когда новая версия компонента установлена в систему, слой CSI опрашивает хранилище компонентов с целью определить, какие именно компоненты обновлены. В процессе установки компонента, CSI использует модуль Очереди простых операций (Primitive Operations Queue, POQ), который считывает список всех файлов и ключей реестра, подлежащих установке/обновлению. Продвинутые установщики или универсальные команды затем запускаются для завершения установки. Расширенные установщики запускаются в контексте процессов с использованием CMI. Если в процессе инсталляции компонента имеет место какой-либо сбой, CSI откатывает всю цепочку изменений, сделанных текущей инсталляцией. Если файл или процесс во время инсталляции компонента используется каким-либо источником и не может быть заменен, действия универсальных команд и продвинутых установщиков заносятся в файл %WinDir%WinSXSPending.xml, и затем эти операции над файлами выполняются уже во время последующей перезагрузки. Если несколько пакетов устанавливаются в одно и то же время, каждый последующий (кроме первого) пакет добавляется к pending.xml. Логгирование на протяжении процесса обновления производится в файл %windir%LogsCBSCBS.log.

Заключение

Зачем нам нужна подобная избыточная компонентная модель, в которой хранятся все версии всех компонентов и пакетов? Действительно, вся эта структура, в которой хранится содержимое компонентов и пакетов предыдущих версий может показаться на первый взгляд абсурдной, тем не менее этот механизм может поддерживать систему в актуальном состоянии при любых обстоятельствах. При любых откатах или удалениях вам нужно всего-лишь перепроецировать компоненты, которые находятся в хранилище в промежуточном статусе. Проекция производится по последнему имеющемуся в хранилище компоненту, надо всего-лишь перестроить зависимости.
В релизы Windows Vista и 7, обслуживание на основе компонентов (компонентная модели) были внедрены в недоработанном, «сыром» виде, что повлекло за собой большое количество проблем у пользователей, выражавшихся в возникновении разнородных ошибок обновлений.
Избыточная сложность компонентной модели, разнообразные уровни/виды составляющих её сущностей, скорее говорят нам о том, что модель явно находится в промежуточном (разрабатываемом) состоянии, и с большой вероятностью будет кардинально меняться в очередных версиях операционных систем.

• ТВикинариум
• Форум
• Поддержка
• PRO
• Войти

ФорумXpucT2022-08-18T02:06:35+03:00

Вы должны войти, чтобы создавать сообщения и темы.

Удаление неудаляемых Обновлений Windows из папки «Packages» [Решено]

Цитата: Psydiant от 10.11.2022, 22:50

Всем Привет!
Есть обновления Windows, которые нельзя удалить стандартными методами через «Панель управления» => «Программы и компоненты» => «Просмотр установленных обновлений» , но эти обновления можно удалить из папки «Packages», которая располагается по адресу: C:WindowsservicingPackages. Якобы эти обновления являются важными компонентами для системы. Обновления, которые мы удаляем из папки «Packages», в окне «Установленные обновления» пропадают. Суть вопроса такая: поскольку других методов я не нашёл, как удалять такие обновления, то можно ли считать данный метод удаления обновлений полноценным? или останутся какие-нибудь хвосты?

Всем Привет!
Есть обновления Windows, которые нельзя удалить стандартными методами через «Панель управления» => «Программы и компоненты» => «Просмотр установленных обновлений» , но эти обновления можно удалить из папки «Packages», которая располагается по адресу: C:WindowsservicingPackages. Якобы эти обновления являются важными компонентами для системы. Обновления, которые мы удаляем из папки «Packages», в окне «Установленные обновления» пропадают. Суть вопроса такая: поскольку других методов я не нашёл, как удалять такие обновления, то можно ли считать данный метод удаления обновлений полноценным? или останутся какие-нибудь хвосты?

Голосуйте — палец вниз.0Голосуйте — палец вверх.0

Цитата: Сергей от 10.11.2022, 23:00

Psydiant, привет 🖐
Обновления Windows считывают свои пакеты, а затем размещают свои файлы в WinSxS и Windows.
Не рекомендуется удалять файлы просто так, не зная, зачем эти файлы нужны.
Чтобы грамотно и безопасно почистить кеш обновлений, нужно использовать Очистку в Win 10 Tweaker.

Psydiant, привет 🖐
Обновления Windows считывают свои пакеты, а затем размещают свои файлы в WinSxS и Windows.
Не рекомендуется удалять файлы просто так, не зная, зачем эти файлы нужны.
Чтобы грамотно и безопасно почистить кеш обновлений, нужно использовать Очистку в Win 10 Tweaker.

Голосуйте — палец вниз.0Голосуйте — палец вверх.1

Цитата: Psydiant от 11.11.2022, 00:00

Цитата: Сергей от 10.11.2022, 23:00

Psydiant, привет
Обновления Windows считывают свои пакеты, а затем размещают свои файлы в WinSxS и Windows.
Не рекомендуется удалять файлы просто так, не зная, зачем эти файлы нужны.
Чтобы грамотно и безопасно почистить кеш обновлений, нужно использовать Очистку в Win 10 Tweaker.

Спасибо за инфу! Удалял только вот эти обновы в качестве эксперимента. Бэкапы есть если что)

Цитата: Сергей от 10.11.2022, 23:00

Psydiant, привет
Обновления Windows считывают свои пакеты, а затем размещают свои файлы в WinSxS и Windows.
Не рекомендуется удалять файлы просто так, не зная, зачем эти файлы нужны.
Чтобы грамотно и безопасно почистить кеш обновлений, нужно использовать Очистку в Win 10 Tweaker.

Спасибо за инфу! Удалял только вот эти обновы в качестве эксперимента. Бэкапы есть если что)

Голосуйте — палец вниз.0Голосуйте — палец вверх.0

Цитата: Psydiant от 13.11.2022, 19:37

Приветствую!
Выяснил что эти обновления устанавливаются вместе с Windows. Как минимум на сборке Windows 10 Pro 19044.1288.
Вот их подробное описание и за что они отвечают:
1) Обновление безопасности для Microsoft Windows (KB5006670) — Обновление относится к работе принтера и всё что связано с печатью, включая также и сетевую печать.
2) Обновление для Microsoft Windows (KB5004331) — Обновление, включающее патчи стабильности и надежности программной среды .NET Framework 3.5 и 4.8.
3) Feature Update to Windows 10 21H2 via Enablement Package (KB5003791) — Обновление необходимо для активации Windows. Если система уже активирована, то после удаления этого обновления активация сразу слетает!
4) Servicing Stack 10.0.19041.1220 — Обновления стека обслуживания (Servicing stack update) содержат исправления для стека обслуживания — компонента, который устанавливает обновления Windows. Кроме того, он содержит Component Based Servicing (CBS), который является ключевым базовым компонентом для нескольких элементов развертывания Windows, таких как DISM, SFC, изменение функций или ролей Windows и восстановление компонентов. CBS — это небольшой компонент, для которого обычно не выпускаются ежемесячные обновления. Обслуживание обновлений стека повышает надежность процесса обновления, чтобы устранить потенциальные проблемы при установке последних исправлений и обновлений функций. Если вы не установите последнее обновление стека обслуживания, существует риск того, что ваше устройство не сможет быть обновлено до последних исправлений безопасности Майкрософт.

-Что такое CBS.log? CBS или Component-Based Servicing — это файл, содержащий логи об установленных и удаленных компонентах Windows Update. Таким образом, информация о вашем Windows Update хранится в этих файлах журнала, даже System File Checker (SFC) пишет в CBS.log.
Расположение файла CBS.log:
C:WindowsLogsCBSCBS.log

p.s. Исходя из этого делаем вывод, что удалять эти обновления не стоит! Не зря отсутствует возможность их удаления стандартными средствами Windows.

Приветствую!
Выяснил что эти обновления устанавливаются вместе с Windows. Как минимум на сборке Windows 10 Pro 19044.1288.
Вот их подробное описание и за что они отвечают:
1) Обновление безопасности для Microsoft Windows (KB5006670) — Обновление относится к работе принтера и всё что связано с печатью, включая также и сетевую печать.
2) Обновление для Microsoft Windows (KB5004331) — Обновление, включающее патчи стабильности и надежности программной среды .NET Framework 3.5 и 4.8.
3) Feature Update to Windows 10 21H2 via Enablement Package (KB5003791) — Обновление необходимо для активации Windows. Если система уже активирована, то после удаления этого обновления активация сразу слетает!
4) Servicing Stack 10.0.19041.1220 — Обновления стека обслуживания (Servicing stack update) содержат исправления для стека обслуживания — компонента, который устанавливает обновления Windows. Кроме того, он содержит Component Based Servicing (CBS), который является ключевым базовым компонентом для нескольких элементов развертывания Windows, таких как DISM, SFC, изменение функций или ролей Windows и восстановление компонентов. CBS — это небольшой компонент, для которого обычно не выпускаются ежемесячные обновления. Обслуживание обновлений стека повышает надежность процесса обновления, чтобы устранить потенциальные проблемы при установке последних исправлений и обновлений функций. Если вы не установите последнее обновление стека обслуживания, существует риск того, что ваше устройство не сможет быть обновлено до последних исправлений безопасности Майкрософт.

-Что такое CBS.log? CBS или Component-Based Servicing — это файл, содержащий логи об установленных и удаленных компонентах Windows Update. Таким образом, информация о вашем Windows Update хранится в этих файлах журнала, даже System File Checker (SFC) пишет в CBS.log.
Расположение файла CBS.log:
C:WindowsLogsCBSCBS.log

p.s. Исходя из этого делаем вывод, что удалять эти обновления не стоит! Не зря отсутствует возможность их удаления стандартными средствами Windows.

Голосуйте — палец вниз.0Голосуйте — палец вверх.1

Приветствую друзья! Смотрите, SetupHost.exe или Modern Setup Host является важной управляющей службой, отвечает за запуск/остановку RPC-процессов во время обновлений Windows 10.

Процесс активен когда происходят обновления, а также при переходе с семерки на десятку. Еще служба участвует в запуске других системных компонентов.

Стоп, стоп, стоп. Скажу сразу — нет универсального рецепта как успокоить нагрузку от SetupHost.exe (Modern Setup Host) — он грузит, как правило когда происходит работа с обновлениями. Если в этом деле будет глюк, косяк, то процесс может грузить долго. Однако и сама работа с обновами может быть пару часов — это только при установки большого количества обнов или при переходи с семерки на десятку. Несколько советов я дам. А также способ, как радикально-агрессивно успокоить SetupHost.exe))

Можем уже сделать вывод — процесс SetupHost.exe системный, имеет отношение к обновлениям. Однако на офф форуме Microsoft нашел иную инфу — Modern Setup Host это установщик, который запускает задания из планировщика во время входа пользователя в систему. Возможно задания тоже связаны с обновлениями, например их поиск, или некоторые внутренние служебные работы.

Кстати у одного юзера Modern Setup Host грузит процессор нереально. Что он только не делал — ничего не помогало. В итоге он просто вернул ноутбук в магазин и просил его обменять на другой. А все потому, что программисты из Microsoft не могут убрать косяки в Windows 10!!!

Пример — идет процесс установки обновлений, в это время в диспетчере висит setuphost.exe и.. может даже не нагружать процессор, но оперативы кушать все равно будет около 200 мегов:

Возможно нагрузка происходит именно при установке обновы.

Нашел еще одну картинку — здесь грузит процесс уже реально, и оперы неприличного много использует:

Сразу хочу сказать — да, это похоже на норму. Когда я устанавливал новую винду и потом запускал обновление — комп тоже тупил, а оперативки системный процесс (точно не помню какой) — тоже много кушал. Очень много, и 2 гига бывало и 3, я не шучу. Но у меня правильное решение было одно — подождать пока все закончится. Когда Windows 10 ставит одно обновление-два, то такой нагрузки нет, но все равно, во время установки лучше компом не пользоваться.

У себя на ПК поискал SetupHost.exe, оказалось у меня он лежит здесь:

C:WindowsservicingLCUPackage_for_RollupFix~31bf3856ad364e35~amd64~~18362.295.1.5amd64_microsoft-windows-setup360-media-base_31bf3856ad364e35_10.0.18362.267_none_801d8c0506453fc5r

C:WindowsservicingLCUPackage_for_RollupFix~31bf3856ad364e35~amd64~~18362.295.1.5amd64_microsoft-windows-setup360-media-base_31bf3856ad364e35_10.0.18362.267_none_801d8c0506453fc5f

Похожие названия папок. А также стоит обратить внимание на название папки servicing — что означает сервисное что-то, а название Package означает пакет. Другими словами — и правда имеет отношение к обновлениям.

SetupHost.exe грузит процессор — что делать?

Некоторые советы, которые возможно помогут решить проблему:

1. Самое первое и самое главное — оставить ПК на час. На два, на три. На ночь. Только проверьте что у вас ПК автоматом не уходит в спящий режим через некоторое время. Пусть Windows уже сделает свои дела, если процессор слабый, то на это может уйти.. ну так бы сказать прилично времени. Поэтому и говорю — на час, на два, а лучше на ночь.
2. Отключить SetupHost.exe вручную. Открыть диспетчер задач, пойти на вкладку Подробности, найти SetupHost.exe > нажать правой кнопкой и выбрать Снять задачу. Однако во-первых процесс через пару секунд может запуститься снова. Во-вторых также есть вероятность что после включения винды он запустится. Как вы понимаете, после запуска — снова может грузить ПК.
3. Использовать радикальный способ. На свой страх и риск, только при условии ранее созданной точки восстановления, а лучше сделать весь образ системы. Агрессивное отключение — сделать так, чтобы процесс больше не смог запускаться. Разумеется при этом могут быть проблемы с обновлениями, учтите это.

Можно еще конечно обратиться на форум Microsoft, расписать свою проблему, как возникает, последствия.. Но там вечно отвечают шаблонными сообщениями, реальной помощи нет, а самый частый ответ — проверьте целостность файлов командой sfc /scannow — я не спорю, команда полезная.. но они ее советуют чуть ли не при всех проблемах. Но можете проверить и вы: запустите командную строку от администратора, вставьте команду sfc /scannow нажмите энтер, дождитесь окончания работы.

Агрессивный способ отключения SetupHost.exe

Суть:

1. Вы переименовываете файл SetupHost.exe в SetupHost.exe_ (оригинальное название сохраните лучше сохранять).
2. Выполняете перезагрузку.
3. В итоге файла SetupHost.exe больше нет. Есть SetupHost.exe_ — но это файл с другим названием. В итоге SetupHost.exe уже запуститься не сможет. Правда есть вероятность что он самовосстанавливается.. сори, у меня не было возможности проверить.
4. Минус — данный способ отключения может нарушить обновления винды. То есть она их может перестать получать, я имею ввиду даже если вернуть оригинальное название файлу.

Сперва настоятельно рекомендую создать точку восстановления! Откройте панель управления > значок система > защита системы > выбираем системный диск > кнопка создать, далее пишите название точки, например До отключения SetupHost.exe и создаете точку.

Алгоритм действий:

1. Сперва самое главное — вам нужно скачать и установить утилиту Unlocker. Она безопасна. Но некоторые антивирусы ругаются, а все потому, что утилита Unlocker нужна чтобы переименовать или удалить заблокированный файл.
2. Идете в диспетчер задач на вкладку Подробности.
3. Находите SetupHost.exe, нажимаете правой кнопкой по нему, выбираете пункт открыть расположение. Вам нужно открыть папку, откуда запускается процесс.
4. Нажимаете правой кнопкой по SetupHost.exe, выбираете пункт Unlocker.
5. Появится менюшка, вам нужно выбрать Переименовать.
6. Укажите новое название, советую при этом сохранять старое, поэтому лучше переименовать в SetupHost.exe_.
7. Может сразу не получится — тогда Unlocker предложит сделать перезагрузку чтобы переименовать. Это нормально.

Окошко Unlocker, где нужно будет выбрать пункт переименовать:

Собственно само переименование:

Данный способ я использовал раньше иногда при некоторых проблемах. Он рабочий, только если файл сам не восстанавливается после переименования.

Заключение

Выяснили:

1. SetupHost.exe (Modern Setup Host) — системный процесс, имеет отношение к обновлениям Windows 10.
2. То, что SetupHost.exe грузит ПК — нормально. Ненормально, когда это длится бесконечно. Если пару часов — да, такое бывает, особенно на слабых ПК. Редко, но бывают обновы, требующие для установки много ресурсов, после того как сделается — нагрузки уже быть не должно.
3. Отключить — неизвестно как, ибо нагрузка SetupHost.exe создается задачей, связанной с обновлением. Можно отключить в диспетчере, но скорее всего все вернется. Можно агрессивно отключить SetupHost.exe — может помочь, однако с обновлением могут быть проблемы, поэтому создание точки восстановления — обязательно.

Удачи, надеюсь инфа кому-то помогла.

На главную!

07.09.2019

Кто сейчас на конференции

Сейчас этот форум просматривают: arvin, mal333 и гости: 8

Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения

Лаборатория