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

Метки:  , , , , , ,

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

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

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

Разновидности повреждений

Причина 1: отсутствующий файл

в лог-файле %WinDir%\Logs\CBS\CBS.log можно встретить сообщения о битых файлах такого вот рода:

Очевидно, что строки, содержащие ключевые слова Cannot repair member file.. указывают на то, что:

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

Ниже по тексту можно найти ошибку STATUS_OBJECT_NAME_NOT_FOUND, указывающую на отсутствие подкаталога. В нашем случае, как видно из отчета, повреждению подверглась целая иерархия компонента, состоящая из подкаталогов и файлов, размещавшаяся в каталоге C:\Windows\WinSxS\amd64_prnbr002.inf_31bf3856ad364e35_6.1.7600.16385_none_49c93aa2c4304e9e. Заглянув в целевой каталог, я убедился, что он действительно пуст, а вот что за событие/действие удалило его содержимое, остается только гадать, хотя подобные инциденты в Windows-системах сплошь и рядом.

Причина 2: Расхождение контрольной суммы

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

В этом случае стек обслуживания компонентов (CSI) сообщает нам, что он не может перепроецировать системный файл C:\WINDOWS\Provisioning\Microsoft-Desktop-Provisioning-Sequence.dat, потому как информация в хранилище так же повреждена.

Причина 3: поврежденный или нулевой файл

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

unable-to-install-kb

В процессе изучения инцидента, в лог-файле %WinDir%\Logs\CBS\CBS.log были обнаружены следующие ошибки:

Ключевые слова, на которые в данном случае стоит обращать внимание, это:

  • Manifest hash for component .. does not match expected value.
  • Unable to load manifest for component ..

Из чего следует, что в данном случае возникла проблема с файлом wow64_microsoft-windows-directshow-core_31bf3856ad364e35_6.1.7601.24382_none_0f268a5b523efde9.manifest, который является манифестом и располагается в поддиректории %SystemRoot%\WinSxS\Manifests. При более близком изучении было выяснено, что указанный файл почему-то нулевой.

Причина 4: попытка удаления отсутствующего компонента

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

Судя по всему установщик ругается на попытку удаления отсутствующего компонента amd64_microsoft-windows-w..lient-aux.resources_31bf3856ad364e35_7.6.7601.23775_ru-ru_306f57c17eac5f89 из пакета Package_846_for_KB4019265~31bf3856ad364e35~amd64~~6.1.1.3.4019265-2966_neutral_LDR. Сам компонент оказался на месте вместе со собственным манифестом, поэтому не понятно что же не нравится стеку обслуживания. Тем не менее что-то с этим пакетом явно не так.

Автоматическое восстановление хранилища

Windows 7:

В версии операционной системы Windows 7, до определенного момента, для решения проблемы восстановления хранилища компонентов разработчиками рекомендовалось специализированное Средство проверки готовности системы к обновлению (System Update Readiness Tool). Оно было призвано помочь в устранении проблем, препятствующих установке обновлений и сервисных пакетов обновлений, иными словами выполняло проверку файлов/ключей хранилища компонентов на всевозможные повреждения. Однако с выпуском обновления KB2966583 появилась возможность использовать утилиту обслуживания компонентов и пакетов DISM, которая была доступна пользователю лишь в версиях Windows 8 и более поздних. Для выполнения процедуры автоматического восстановления хранилища компонентов в Windows 7 и более поздних ОС запустите следующую команду из командной строки (и дождитесь завершения её работы):

dism /Online /Cleanup-Image /ScanHealth

*в Windows 7 отсутствуют привычные нам по новым версиям ключи /RestoreHealth и /CheckHealth.

Windows 10:

В операционной системе Windows 10 синтаксис командной строки утилиты претерпел некоторые изменения. Для восстановления хранилиша компонентов выполняем команду:

dism /Online /Cleanup-Image /RestoreHealth

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

dism /Online /Cleanup-Image /RestoreHealth /Source:C:\RepairSource\Windows /LimitAccess

*где параметр /Source указывает местоположение рабочей копии.

Результаты работы

Операция по восстановлению выполняется довольно продолжительное время, а результатом будет сообщение вида: "Выполнение операции scanhealth завершено, см. журнал по адресу %windir%\logs\CBS\Checksur.log. Операция успешно завершена."

Как можно увидеть из снимка экрана, вся информация о результатах восстановления содержится в файле %WinDir%\Logs\CBS\CheckSUR.log:

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

Ручное восстановление хранилища

Используйте восстановление в ручном режиме только в том случае, когда восстановление в автоматическом режиме не дало положительного результата!

При всех стараниях разработчиков из Microsoft предоставить возможность конечному пользователю системы устранять возникающие проблемы в автоматическом режиме (при помощи специальных утилит), никогда полностью не будут исключены ситуации, в которых эти самые автоматизированные средства будут давать сбои. Причина тут кроется в симбиозе старых механизмов операционной системы и необходимостью постоянного внедрения новых (сырых) технологий, должным образом не заботясь о приведении в надлежащее состояние всех связанных (участвующих) компонентов, что, в свою очередь, порождает огромное количество проблем. Поэтому, всегда надо иметь средство на крайний случай, то есть уметь восстановить работоспособность вручную. В любом случае, ручное восстановление хранилища компонентов всегда начинается с анализа лог-файла компонентной модели: %WinDir%\Logs\CBS\CBS.log.

Поиск рабочих экземпляров файлов

Методика восстановления хранилища компонентов сводится к поиску рабочих копий поврежденных или отсутствующих файлов на аналогичной, максимально приближенной по версиям, полностью рабочей системе. Для этого, после исследования файла %WinDir%\Logs\CBS\CBS.log и составления списка проблемных файлов, выполняем поиск аналогичных файлов (по строго аналогичным путям) на нормально-функционирующей системе (желательно той же версии обновлений).
Расширения, имена файлов компонента и соответствующие им пути, которые (обычно) подлежат замене:

  • .cat и .mum - файлы компонента -- каталог %WinDir%\servicing\Packages;
  • .manifest-файлы компонента -- каталог %WinDir%\WinSxS\Manifests;
  • Остальные файлы компонента (.exe, .dll и другие) -- каталог %WinDir%\WinSxS\имя_компонента\;

Сброс безопасности

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

Поскольку объекты в иерархии директорий %WinDir%\Logs\CBS\CBS.log защищены, непосредственно перед копированием, необходимо выполнить подготовительные действия по смене владельца необходимых каталогов и поврежденных целевых системных файлов.
Для этого выполним следующую команду:

takeown /f полный_путь_к файлу\имя_файла

Например:

сменить владельца takeown

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

icacls полный_путь_к файлу\имя_файла /GRANT АДМИНИСТРАТОРЫ:F

Например:

назначение прав icacls

Копирование в целевую систему

И уже в финальной части, можно наконец-то скопировать работоспособные копии восстанавливаемых файлов компонента/пакета на место поврежденного:

  1. Если повреждены/отсутствуют .cat или .mum файлы компонета, то скопировать их в каталог %WinDir%\servicing\Packages;
  2. Если поврежден/отсутствует .manifest-файл (манифест) компонента, то скопировать его в каталог %WinDir%\WinSxS\Manifests;
  3. Если повреждены/отсутствуют остальные файлы компонента, то скопировать их в каталог %WinDir%\WinSxS\имя_компонента\;

сделать это можно как при помощи командной строки, так и выполнить перемещение с помощью проводника Windows.

Восстановление при помощи средства проверки готовности системы к обновлению (SURT)

Метод подходит только для операционной системы Windows 7. Для более новых ОС (Windows 8+) средство SURT не требуется, поскольку весь функционал встроен в систему: рекомендовано пользоваться Powershell или утилитой dism.exe.

Средство проверки готовности системы к обновлению (SURT, CheckSUR) представляет собой набор файлов компонентов, (до некоторого времени) регулярно обновляемый по мере выхода новых исправлений. Скачиваем пакет KB947821 для вашей версии и разрядности системы. Запускаем с повышенными привилегиями. После окончания установки (статус: Установка завершена) проверяем лог-файл %Windir%\Logs\CBS\CheckSUR.log на предмет наличия записей об ошибках:

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

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

  • *.mum- и *.cat-файлы из C:\Windows\servicing\Packages складываются в %Windir%\Temp\CheckSUR\servicing\packages;
  • *.manifest-файлы из C:\Windows\winsxs\Manifests складываются в %Windir%\Temp\CheckSUR\winsxs\manifests\;

После окончания копирования файлов необходимо повторно запустить SURT, используя уже скачанный файл обновления KB947821. При повторном запуске средство проверки готовности системы к обновлению сможет подхватить скопированные нами с рабочей системы эталонные файлы из каталога %Windir%\Temp\CheckSUR и заменить ими испорченные. Если процедура восстановления завершилась успешно, то в лог-файле %Windir%\Logs\CBS\CheckSUR.log можно будет увидеть следующие записи:

В случае отсутствия ошибок (статус: No errors detected) можно возобновить установку ранее неустанавливаемых обновлений на целевую машину.

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

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

cleanmgr

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

очистка диска

..после чего в списке в обязательном порядке маркируем пункты: "Временные файлы установки Windows" и "Очистка обновлений Windows" и нажимаем OK. Дожидаемся окончания процесса очистки, после чего может потребоваться перезагрузка (о чем нам сообщают в описании некоторых пунктов).
Судя по тому, что при вызове утилиты cleanmgr.exe в списке активных процессов появляется процесс с именем DismHost.exe, могу с некоторой вероятностью предположить, что аналогичный описанному выше функционал доступен через утилиту обслуживания образов dism.exe с определенными ключами.

Восстановление файлов компонента из пакета обновления

Иногда возникают трудности с поиском рабочих копий поврежденных файлов на уже развернутых боевых системах, по разнообразным причинам найти не удается. Ну бывает, что делать, кто-то неправильно ввел шаблон поиска, кто-то использовал встроенный поиск, который при неправильных настройках не дает результатов. В подобной ситуации у нас имеется одно запасное элегантное решение: найти обновление, в состав которого входят искомые (поврежденные) файлы. При анализе лога %WinDir%\Logs\CBS\CBS.log иногда можно увидеть, что проблемный компонент входит в состав какого-либо обновления:

Очевидно, что компонент amd64_microsoft-windows-w..lient-aux.resources_31bf3856ad364e35_7.6.7601.23775_ru-ru_306f57c17eac5f89 входит в состав пакета Package_846_for_KB4019265~31bf3856ad364e35~amd64~~6.1.1.3.4019265-2966_neutral_LDR, который, в свою очередь, является частью KB4019265. В этом случае можно выполнить следующую последовательность действий:

  1. Скачать файл KB??????? для требуемой разрядности/системы с сайта Microsoft (ссылка элементарно ищется через любой поисковик);
  2. Распаковать содержимое файла обновления в произвольную временную директорию. пример:

    expand -F:* windows6.1-kb4019265-x64_c21fb9314da54cf6bd7972581da3159535f55aec.msu c:\temp\4019265

  3. Поместить искомые распакованные файлы в местоположения в соответствии со следующими рекомендациями:
    • .cat и .mum - файлы компонента -- каталог %WinDir%\servicing\Packages;
    • .manifest-файлы компонента -- каталог %WinDir%\WinSxS\Manifests;
    • Остальные файлы компонента (.exe, .dll и иные) -- каталог %WinDir%\WinSxS\имя_компонента\;

Удаление пакета, включающего проблемный компонент

На практике попадаются и такие ошибки, когда стек обслуживания не в состоянии удалить определенную версию компонента, о чем он и сообщает в логах (%WinDir%\Logs\CBS\CBS.log):

Ну что же, попробуем ему в этом помочь. По тем же логам вычисляем наименование пакета, в нашем случае это Package_846_for_KB4019265~31bf3856ad364e35~amd64~~6.1.1.3.4019265-2966_neutral_LDR. После чего попробовать удалить его при помощи утилиты dism:

dism /Online /Remove-Package /PackageName:Package_846_for_KB4019265~31bf3856ad364e35~amd64~~6.1.1.3.4019265-2966_neutral_LDR /norestart

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

Выводы

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

2 комментария:

  1. Denis

    Бывает когда "dism /Online /Cleanup-Image /ScanHealth" отрабатывает ошибок нет, установка KB947821 тоже без ошибок, а обновление не ставится но обнаруживается какой то из компонентов WinSxS поврежден - помогает запуск стандартной очистки системного диска с выбором "Очистка обновлений" и прочих системных файлов. Но это помогло раза два из десяти.

    • shofixti

      а вот это ценная информация!! надо будет изучить вопрос и добавить одним из методов. спасибо!

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Помощь сайту