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

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

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

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

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

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

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

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

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

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

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:\Windows\WinSxS). Разработчики уверяют что папка WinSxS является хранилищем разных версий общих библиотек и представляет собой "установочное и обслуживаемое состояние" всех системных компонентов.

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

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

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

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

Реестр

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

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing;
• HKEY_LOCAL_MACHINE\Schema;
• HKEY_LOCAL_MACHINE\COMPONENTS - временный, подключаемый на время обслуживания, ключ реестра. Импортируется из файла C:\Windows\system32\config\COMPONENTS;

соответственно, в ключе HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages перечисляются все установленные в системе пакеты.

Для того, что бы была возможность работать со списком пакетов, необходимо назначить правильные права на весь раздел 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)

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

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

Это порождает довольно интересный, ранее не встречавшийся в Windows, алгоритм обновления: в процессе установки библиотеки, уже имеющейся в системе, факт наличия обнаруживается, однако файл библиотеки DLL не перезаписывается, вместо этого новая версия помешается в папку 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 компонентов. Так что же это тогда такое? Давайте разбираться.

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

Пакеты (Packages)

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

• одна часть пакета располагается в хранилище пакетов, то есть дереве директорий с корнем в %WinDir%\servicing\Packages. В нем содержатся конфигурационные файлы пакета, тут каждый установленный пакет/обновление представлен двумя файлами: файлом каталога безопасности (.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)

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

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

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

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

• Манифест компонента (файл с расширением .manifest) – паспорт компонента Windows. Манифест компонента задает его зависимости от имен, версий, ресурсов и других компонентов, в нем указываются различные параметры компонента, такие как наименование, каталог установки, параметры (ключи) реестра, исполняемые файлы, наименования служб и прочие. Манифест определяет как именно файлы группируются по компонентам. Имя файла манифеста включает имя соответствующей сборки, размещаемой в каталоге %WinDir%\WinSxS. Размещается в каталоге %WinDir%\WinSxS\Manifests;
• Манифест пакета или обновления (файл с расширением .mum) - паспорт пакета/обновления Windows. В нем указываются различные параметры пакета: наименование, идентификатор, язык установки, зависимости. Этот типа манифеста используется в качестве идентификатора (символического имени) сервиса обслуживания, для выполнения над пакетом операций включения/отключения/удаления посредством различных сервисных утилит (DISM, pkgmgr). Имя файла манифеста включает имя соответствующего пакета, размещаемого в каталоге %WinDir%\WinSxS. Размещается в каталоге %WinDir%\servicing\Packages;
• Манифест приложения (файл с именем основного приложения, двойным расширением .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)).

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

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

CSI

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

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

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

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

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

Заключение

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