Cbs log как найти ошибку

В данной статье описан метод ручного восстановления хранилища компонентов Windows. Подобные описанному в данном посте методу восстановления работоспособности компонентной модели рождаются вовсе не от хорошей жизни, появляются они под воздействием многочисленных проблем с компонентной моделью операционной системы. Во многих случаях официальные подходы к восстановлению хранилища компонентов не помогают, помимо этого отсутствует какая бы то ни было внятная официальная документация, из чего складывается недопонимание структуры и принципов работы компонентной модели. При подобном отношении со стороны разработчиков абсолютно любые средства вернуть компонентную модель в работоспособное состояние приемлемы!! Как показывает практика, при всех стараниях разработчиков из Microsoft предоставить возможность конечному пользователю системы устранять возникающие проблемы в автоматическом режиме (при помощи специальных утилит), никогда полностью не будут исключены ситуации, в которых эти самые автоматизированные средства будут давать сбои. Причина тут кроется в симбиозе старых механизмов операционной системы и необходимостью постоянного внедрения новых (не оттестированных) технологий, должным образом не заботясь о приведении в надлежащее состояние всех связанных (участвующих) компонентов, что, в свою очередь, порождает огромное количество проблем.
В данной публикации речь пойдет о восстановлении компонента прямой заменой файлов. Фактически методом предусматривается прямая ручная замена поврежденных [кривых, неправильно функционирующих] файлов, являющихся причиной возникновения ошибок, а так же частей реестра. По этой методике, исправные файлы и соответствующие ключи реестра копируются с работоспособной станции-донора. Слабое место метода в том, что для реализации требуется наличие находящейся на том же уровне обновлений нормально функционирующей операционной системы той же версии/ревизии.
В процессе повествования постараемся описать общую методику, тем не менее, в статье будут присутствовать частные случаи из практики.

Определение виновника проблемы

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

Ошибки в лог-файлах

Основной и пожалуй самый информативный источник о проблемах, связанных с компонентной моделью Windows — лог-файлы системных утилит обслуживания. Чаще всего ошибки выявляются при выполнении обновления системы, то есть установки обновлений/исправлений. Проявляются они в виде разнообразных ошибочных статусов в интерфейсе Центра обновления и окон обновлений. Тем не менее, сам по себе статус не малоинформативен, а вот более детальная информация попадает в специализированные файлы журналов. В данном разделе мы опишем методики поиска источников проблем в лог-файлах результатов работы системных утилит SURT/DISM/SFC/SFCFix, которые работают с хранилищем компонентов и системными каталогами а предмет восстановления целостности компонентной модели системы.

CheckSUR.log / DISM.log

Правила поиска ошибок в файлах %Windir%LogsCBSCheckSUR.log или %Windir%LogsDISMDISM.log:

Статусы (первый символ):

• (f) — фатальная ошибка;
• (w) — предупреждение;
• (fix) — указывает на ошибку, которая была исправлена; выводятся в виде отдельной строки сразу за строкой со статусом (f);

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

CBS.log

Несколько вариантов поиска ошибок в лог-файле %WinDir%LogsCBSCBS.log:

• Производим поиск строк, содержащих ключевое слово Error (с пробелом ДО или ПОСЛЕ). В их окружении можно найти указание на конкретные ошибки;
• Выполняем команду

  findstr /c:»[SR]» %windir%logscbscbs.log > c:sfcdetails.txt

  в результате чего в корне диска C: будет создан файл sfcdetails.txt, включающий лишь строки исходного файла, содержащие префикс [SR] (содержащие информацию об ошибках).

1: отсутствующие компоненты

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

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

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

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

• 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%WinSxSManifests. При более близком изучении было выяснено, что указанный файл почему-то нулевой.
3: попытка удаления отсутствующего компонента
При попытках установки обновления безопасности мы можем столкнуться со следующей проблемой:

Судя по всему установщик ругается на попытку удаления отсутствующего компонента 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, но иногда их можно увидеть в автономных информационных окнах. Например, отказ запуска множества исполняемых системных образов может выражаться в постоянно всплывающих окнах, в заголовке которых можно видеть «<имя_образа> (в контексте которого произошел сбой) — ошибочный образ», а в информационной части текст ошибки: X:XXXXXXxxxxxxxx.dll либо не предназначен для выполнения под управлением Windows или содержит ошибку. Попробуйте переустановить программу с помощью исходного установочного носителя или обратитесь к системному администратору или поставщику программного обеспечения за поддержкой:

В английских версиях в заголовке можно увидеть «<filename> — bad image», а описание звучит как: «<filename> is either not designed to run on Windows or it contains an error. Try installing the program again using the original installation media or contact your system administrator or the software vendor for support.» Часто сообщение в окне дополняется специфической деталью сбоя, например кодом ошибки: «Error status 0xc000012f».

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

В данном случае, как вы можете видеть на снимке экрана выше, у нас повреждена библиотека с именем ncrypt.dll, относительно неё мы и поведем дальнейшее повествование.

Тем не менее, в ваших случаях для выявления виновника сбоя потребуется исследовать лог-файл %WinDir%LogsCBSCBS.log и составить список проблемных файлов. И при не столь очевидных намеках на источник проблемы всегда начинайте исследование сбоя с анализа данного лог-файла.

Восстановление файлов

На предыдущем шаге мы определились в виновником ошибки, то есть определили имена поврежденных/удаленных файлов:

• Если мы наблюдаем ошибку в виде информационного окна в графическом интерфейсе, то виновником обычно является модуль, имя которого фигурирует в тексте (в примере выше: ncrypt.dll). В этом случае мы будем менять все без исключения ревизии проблемного файла;
• Если мы производим разбор лог-файлов отчетов сервисных утилит (CBS/DISM/CheckSur/SFCFix), то виновник(и) проблемы обычно предстают перед нами в виде списка конкретных файлов компонентов или обновлений;

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

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

На этом этапе нам необходимо найти рабочие копии поврежденных или отсутствующих файлов. Существует несколько основных подходов по нахождению рабочих копий:

1. Скопировать файлы с аналогичной, полностью работоспособной системы той же версии/редакции:
• при помощи поиска (в проводнике, или любым специализированным средством типа Far/Total Commander) по системному разделу (обычно C:) находим все каталоги, содержащие в своем названии искомую маску/имя (для случая выше: *ncrypt*). Сокращенный вывод:

  . . . C:Windowswinsxsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24417_none_6072150268f96612 C:Windowswinsxsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18741_none_bbe0d7630856b4a1 C:Windowswinsxsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24408_none_607de53868f06378 C:Windowswinsxsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18812_none_bc024957083d774c C:Windowswinsxsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24387_none_602663a869322c82 C:Windowswinsxsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18869_none_bbd33bc1085fb462 C:Windowswinsxsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24384_none_602362ca6934e07d C:Windowswinsxsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18923_none_bbf87b9b0844a9bb C:Windowswinsxsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24357_none_6046d36c6919d8af C:Windowswinsxsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18933_none_bbedabaf084cc5ac C:Windowswinsxsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24335_none_605a72b0690b6e1f C:Windowswinsxsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18939_none_bbf3ad6b08475db6 . . .

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

  Можно произвести замену файлов и в системных каталогах, таких как C:Windowssystem32. Хотя делать это не обязательно, поскольку файлы там представляет собой жесткие ссылки на оригиналы в хранилище WinSxS, а они восстанавливаются автоматически при проверке через sfc).
• в ходе того же самого поиска, кроме директорий, выявляются и файлы, которые располагаются по следующим путям (вывод сокращен):

  . . . C:WindowswinsxsManifestsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24408_none_bc9c80bc214dd4ae.manifest C:WindowswinsxsManifestsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18741_none_5fc23bdf4ff9436b.manifest C:WindowswinsxsManifestsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24387_none_bc44ff2c218f9db8.manifest C:WindowswinsxsManifestsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18812_none_5fe3add34fe00616.manifest C:WindowswinsxsManifestsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24384_none_bc41fe4e219251b3.manifest C:WindowswinsxsManifestsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18869_none_5fb4a03d5002432c.manifest C:WindowswinsxsManifestsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24357_none_bc656ef0217749e5.manifest C:WindowswinsxsManifestsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18923_none_5fd9e0174fe73885.manifest C:WindowswinsxsManifestsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24335_none_bc790e342168df55.manifest C:WindowswinsxsManifestsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18933_none_5fcf102b4fef5476.manifest C:WindowswinsxsManifestsamd64_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.24308_none_bc9c7ed6214dd787.manifest C:WindowswinsxsManifestsx86_microsoft—windows—ncrypt—dll_31bf3856ad364e35_6.1.7601.18939_none_5fd511e74fe9ec80.manifest . . .

2. Разархивировать требуемые файлы из пакета обновления.
   • Для этого определяем имя обновления KBXXXXXXXX, в состав которого входят обнаруженные на предыдущем шаге файлы, из Центра загрузок Майкрософт или Центра обновления Майкрософт или попросту используя поиск.
   • Распаковываем содержимое выкачанного только что пакета обновления (.msu) в произвольную (временную) директорию:

     expand -F:* windows6.1-kb4019265-x64_c21fb9314da54cf6bd7972581da3159535f55aec.msu c:temp4019265

   • после чего в целевой директории мы увидим следующее содержимое:
     • .xml-файл — метаданные-описатели пакета обновления (.msu). Утилиты установки используют .xml-файл при выполнении установки в автоматическом режиме;
     • .cab-файл — архив с данными (полезная нагрузка) обновления;
     • *-pkgProperties.txt — файл с описанием свойств пакета (дата релиза, архитектура, тип, ссылка на KB и прочее);
     • WSUSSCAN.cab — файл оффлайн-сценария проверки;
   • затем выполняем еще одну команду, теперь уже над только что распакованным .cab-файлом:

     expand -F:* windows6.1-kb4019265-x64.cab c:temp4019265extracted

   • после этого необходимые нам для замены файлы будут располагаться в директории c:temp4019265extracted

Установка безопасности для каталогов/файлов

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

Выполнять приведенные здесь действия следует из-под учетной записи с правами локального Администратора (с эскалацией привилегий).

Сделать это можно двумя способами:

1. Через проводник. Нажимаем правую клавишу мыши на директории WinSxS — пункт Свойства — вкладка Безопасность — кнопка Дополнительно — вкладка Владелец — кнопка Изменить — ставим курсор на нужного нам пользователя, активируем чекбокс Заменить владельца подконтейнеров и объектов — жмем кнопку Применить. После окончания процесс закрываем все открытые окна через кнопку OK, повторно жмем правую клавишу мыши на директории WinSxS — вкладка Безопасность — во фрейме Группы и пользователи кнопка Изменить — выделяем курсором группу Администраторы — ставим разрешения Изменение и Запись;
2. Через командную строку. Из командной строки (cmd) выполняем следующие команды:

   takeown /f c:windowswinsxs*

   

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

   icacls c:windowswinsxs* /GRANT АДМИНИСТРАТОРЫ:F

   

Копирование каталогов/файлов

И последним шагом выполняется непосредственно копирование (с заменой) с донорской (исправной) системы на целевую (проблемную) содержимого всех обнаруженных на предыдущих шагах каталогов и файлов, не забывайте так же и .manifest-файлы.
Что именно мы копируем:

1. Если присутствуют пара .cat или .mum файлов компонента, то скопировать их в каталог %WinDir%servicingPackages (с донора на цель). Копировать именно всю пару, даже если поврежден всего-лишь один из них (и один из них отображается в лог-файле);
2. Если к паре .cat/.mum файлов присутствует еще и .ses-файл, то копируем и его;
3. Если присутствуют одноименные манифесты (.manifest-файл(ы)) компонента, то скопировать их в каталог %WinDir%WinSxSManifests (с донора на цель);
4. Если присутствуют остальные подкаталоги/файлы компонента, то скопировать их в каталог компонента %WinDir%WinSxSимя_компонента (c донора на цель);
5. Если присутствуют файлы в директории C:WindowsSystem32, то можно скопировать и их (с донора на цель). Хотя делать это и не обязательно, поскольку жесткие ссылки восстанавливаются при проверках через sfc;

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

Восстановление реестра

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

• Запустить командную строку (cmd);
• Подключить динамический куст реестра HKLMCOMPONENTS командой:

  reg load HKLMCOMPONENTS C:WINDOWSSYSTEM32CONFIGCOMPONENTS

  если выскакивает ошибка:

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

  то куст уже подключен.

• Запустить редактор реестра regedit;
• В открывшемся окне нажать Ctrl+F и ввести имя компонента, который вы восстанавливали на предыдущем шаге;
• В случае отсутствия каких либо записей реестра, выполнить импортирование соответствующих записей реестра о компоненте с рабочей машины;
• Выполнить команду:

  reg unload HKLMCOMPONENTS

• выполнить перезагрузку операционной системы;