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

Метки:  ,

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

Возможные причины

Причина 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: Расхождение контрольной суммы

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

В этом случае утилита сообщает нам, что она не может перепроецировать системный файл 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). Это средство было призвано помочь в устранении проблем, препятствующих установке обновлений и сервисных пакетов обновлений операционной системы Windows 7, другими словами проверяло системные файлы на всевозможные повреждения. Однако с выпуском обновления KB2966583 появилась возможность использовать утилиту обслуживания компонентов и пакетов DISM, которая ранее была доступна лишь в версиях Windows 8 и более поздних. Для выполнения процедуры автоматического восстановления хранилища компонентов в Windows 7 и более поздних ОС запустите следующую команду из командной строки и дождитесь завершения её работы:

dism /Online /Cleanup-Image /ScanHealth

Windows 10:

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

dism /Online /Cleanup-Image /RestoreHealth

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

Операция по восстановлению выполняется довольно продолжительное время, а результатом будет сообщение вида: "Выполнение операции 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.

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

Иногда возникают трудности с поиском рабочих копий поврежденных файлов на уже развернутых боевых системах, по разнообразным причинам найти не удается. Ну бывает, что делать, кто-то неправильно ввел шаблон поиска, кто-то использовал встроенный поиск, который при неправильных настройках не дает результатов. В подобной ситуации у нас имеется одно запасное элегантное решение: найти обновление, в состав которого входят искомые (поврежденные) файлы. При анализе лога %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%\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

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

Выводы

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

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

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