Защита ресурсов Windows не может выполнить запрошенную операцию. Опять ошибка. Защита ресурсов не может выполнить запрошенную операцию виндовс 10


Защита ресурсов Windows не может выполнить запрошенную операцию

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

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

Содержание статьи:

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

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

Далее в статье все примеры будут показаны именно на ее примере. Хотя большой разницы нет, главное понять суть процесса, что позволит восстановить критические повреждения Windows без участия дополнительного ПК.

Итак, выставляем в БИОС загрузку с USB-накопителя на основе WInPE и загружаемся. После этого открываем имеющийся в сборке файловый менеджер Total Commander и находим каталог с образом установочного дистрибутива системы. Жмем по нему правой кнопкой мыши и выбираем пункт "Подключить образ к ImDisk":  

На следующем шаге происходит монтирование ISO-образа в виртуальный привод. В нашем случае он числится под буквой "H":

Так, далее следует выбрать указанный выше дисковод и найти в папке "Sources" инсталляционный архив под именем "Install.esd" либо "Install.wim". Если вы внимательно читали прошлые публикации на эту тему, то должны знать про эти файлы.

Затем в правой панели файлового менеджера нужно открыть любой логический раздел жесткого диска компьютера, главное, чтобы он был несистемным и имел свободное пространство не менее 20 Гб.

Возвращаемся обратно к установочному образу Windows 10, жмем правой кнопкой мыши и выбираем "7-Zip-Распаковать в install":

Начнется довольно долгий процесс распаковки. Насколько долгий? Посмотрите на размер конечного файла и сделайте выводы сами:

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

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

Кто сейчас не совсем понимает о чем идет речь, обязательно пройдите по ссылке выше и внимательно ознакомьтесь с материалом. А мы же жмем комбинацию клавиш "Shift+F10" и вводим соответствующую команду:

Notepad

На следующем шаге идем в блокноте по пути "Файл-Открыть", выбираем опцию "Все файлы" и кликаем по разделу "Мой компьютер":

На картинке выше видно, что под буквой "D" значится загрузочная флешка, "E", это системный раздел с неисправной системой Windows 10, а "F", второй логический раздел с пользовательскими файлами (фильмы, музыка и т.д.).

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

sfc /scannow /offbootdir=F:\Install\ /offwindir=E:\Windows

Теперь давайте расшифруем. "F:\Install", это раздел с папкой, в которую были распакованы системные файлы из хранилища. "E:\Windows", диск с установленной неисправной системой. Как видите, все очень даже просто.

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

С уважением, Комаровский Виталик

Обновлено: 25.02.2018 — 15:47

pronetblog.by

Наилучший способ восстановления нарушения целостности системных файлов

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

целостность системных файлов

Но что же делать, когда это не так? И проверка целостности системных файлов Windows оповещает противоположное тому, что было описано выше. (Защита ресурсов Windows обнаружила повреждённые файлы, но не удалось исправить некоторые из них. Подробные сведения см. в файле CBS.log…).

целостность системных файлов

Конечно, можно переустановить операционную систему, или восстановить её из образа. Можно с помощью той же командной строки, запустить её от имени администратора и использовать команды:

  1. DISM.exe /Online /Cleanup-Image /ScanHealth

  2. DISM.exe /Online /Cleanup-Image /RestoreHealth

То есть вбиваете команду и нажимаете ENTER. Говоря простым и доступным для пользователя языком.

  1. Это сканирование файлов образа системы

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

Но есть ещё один способ, о котором я хочу вам рассказать с самого начала. Данным способом я пользуюсь всё время, и он не раз помогал мне выполнить восстановление целостности системных файлов в тех ситуациях, когда первый был почему-то бессилен. Данный метод базируется на использовании такой программы как Windows PowerShell, и он довольно прост. Запустите программу PowerShell от имени администратора и вбейте строку:

Repair-WindowsImage -Online –RestoreHealth

Простым языком говоря, вы даёте команду отремонтировать, целостность системных файлов из компонентов Windows, зарезервированных у вас на компьютере.

Только данный способ делает это более тщательней, чем тот, что описан выше (с помощью командной строки). Затем нажимаете ENTER.

Далее вот что у вас будет:

целостность системных файлов

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

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

целостность системных файлов

Если это не помогло, остаётся только одно переустановить операционную систему.

12.11.2014

Ещё статьи, которые могут заинтересовать:Ccleaner безупречная очистка операционной системыПопулярный архиватор файлов программа WinRARБесплатный торрент-клиент программа ZonaЗачем оптимизировать жёсткий дискМесторасположения папок Temp в Windows 10

pcompstart.com

Windows 10 SFC /SCANNOW — Инструкция по запуску команды

Windows 10 SFC /SCANNOW Загрузка...

Windows 10 SFC /SCANNOW — это служебная программа в Windows, позволяющая пользователям проверять системные файлы на отсутствие повреждений и восстанавливать поврежденные системные файлы.

В этой статье описывается, как запустить средство проверки системных файлов (Windows 10 SFC /SCANNOW) для сканирования системных файлов и восстановления отсутствующих или поврежденных системных файлов. Если файл программы защиты ресурсов Windows (WRP) отсутствует или поврежден, Windows может работать не так, как ожидается. Например, могут не работать некоторые компоненты или может возникнуть сбой Windows.

Запуск средства проверки системных файлов Windows 10 SFC /SCANNOW

Для этого выполните указанные ниже действия.

  1. Откройте командную строку с повышенными привилегиями. Для этого выполните указанные ниже действия, в зависимости от версии операционной системы: Ищем где командная строка в Windows 10 и запускаем 2 способами
  2. Введите в командной строке приведенную ниже команду и нажмите клавишу ВВОД:

    sfc /scannow

    Снимок экрана для этого этапа.

    Команда sfc /scannow проверит все защищенные системные файлы и заменит поврежденные файлы их кэшированной копией, расположенной в сжатой папке по адресу %WinDir%\System32\dllcache.Заполнитель %WinDir% представляет собой папку операционной системы Windows 10. Например, C:\Windows.

    Примечание. Не закрывайте это окно командной строки, пока проверка не завершится на 100 %. Результаты проверки будут показаны после завершения данного процесса.

  3. После завершения процесса проверки на экране может появиться одно из приведенных ниже сообщений:
    • Защита ресурсов Windows не обнаружила нарушений целостности.

      Это значит, что отсутствующие и поврежденные системные файлы не обнаружены.

    • Защита ресурсов Windows не может выполнить запрошенную операцию.

      Для устранения этой проблемы выполните сканирование с помощью средства проверки системных файлов в безопасном режиме, убедитесь, что папки PendingDeletes и PendingRenames находятся в папке %WinDir%\WinSxS\Temp.

    • Защита ресурсов Windows обнаружила поврежденные файлы и успешно их восстановила. Сведения см. в журнале CBS.Log %WinDir%\Logs\CBS\CBS.log.

      Для просмотра подробных сведений о сканировании и восстановлении системных файлов перейдите к разделу Как просмотреть подробные сведения процесса работы средства проверки системных файлов.

    • Защита ресурсов Windows обнаружила поврежденные файлы, но не может восстановить некоторые из них. Сведения см. в журнале CBS.Log %WinDir%\Logs\CBS\CBS.log.

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

Понравилась статья? Поделиться с друзьями:

akeelow.ru

Sfc - проверка системных файлов

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

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

Sfc (System file checker) - утилита проверки целостности системных файлов операционной системы Windows. Выполняет проход по каталогам, содержащим ключевые системные файлы операционной системы и выполняет восстановление поврежденных или отсутствующих системных файлов.

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

Запуск проверки целостности файлов

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

Поскольку sfc является консольной утилитой (утилитой командной строки), то и запускать её следует из командного интерпретатора cmd. Для выполнения комплексной проверки всех системных файлов, выполните следующую команду:

sfc /scannow

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

сканирование системы sfc

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

  • Защита ресурсов Windows не обнаружила нарушений целостности. Это сообщение говорит о том, что WRP не смогла найти каких-либо повреждений в операционной системе и стоит задуматься о диагностировании системы другими способами;
  • Защита ресурсов Windows не может выполнить запрошенную операцию. Утилита sfc сообщает нам, что WRP не смогла выполнить необходимые операции восстановления. В этом случае можно попробовать запустить sfc, перегрузившись в защищенный режим. Дополнительно удостоверьтесь что папки PendingDeletes и PendingRenames присутствуют в директории %WinDir%\WinSxS\Temp;
  • Защита ресурсов Windows обнаружила поврежденные файлы и успешно их восстановила. В этом случае процесс завершился удачно, ради интереса Вы можете ознакомиться с результатами работы утилиты sfc в файле %WinDir%\Logs\CBS\CBS.log;
  • Защита ресурсов Windows обнаружила поврежденные файлы, но не может восстановить некоторые из них. Утилита сообщает нам о том, что WRP не смогла восстановить некоторые несоответствия. В этом случае у нас, с большой вероятностью, повреждено хранилище компонентов (WinSxS) и у нас имеется два возможных варианта решения проблемы, которые описаны в разделе Восстановление хранилища компонентов.
  • Для завершения восстановления системы требуется перезагрузка. Перезапустите систему Windows и выполните sfc еще раз. Обычно подобная ошибка появляется при запуске из-под ограниченного рабочего окружения, такого, например, как среда восстановления (Windows RE). Для решения проблемы попробуйте запустить утилиту sfc с дополнительными параметрами, как описано в разделе Запуск из среды восстановления.
  • Защите ресурсов Windows не удается запустить службу восстановления. Ошибка говорит нам о том, что службы, от которых зависит работа утилиты, не могут запуститься. Службы, которые могут являться причиной ошибки: "Теневое копирование тома", "Установщик модулей Windows" и "Установщик Windows". Проверьте, возможен ли вообще запуск данных служб, в случае возникновения проблем проверьте зависимости. Иногда причина может крыться в запуске консоли, из-под которой выполняется команда sfc, с ограниченными правами.
  • В данный момент выполняется другая операция обслуживания или восстановления. Дождитесь ее завершения и повторно запустите SFC. Информационное сообщение информирует о том, что в данный момент стек обслуживания занят, одновременно с ним два источника работать не могут. На низком уровне единственный источник, который может работать со стеком обслуживания, это модуль TrustedInstaller.exe. Если Вам прямо уж срочно необходимо освободить стек для произведения собственных манипуляций, то просто попробуйте снять через Диспетчер задач процесс с именем TrustedInstaller.exe, однако имейте в виду, что в этом случае возможны некоторые нюансы :)

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

Алгоритм работы

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

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

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

Сборки бывают приватными и общими. Все общие сборки размещаются в системе в специальном хранилище компонентов, которое располагается в дереве директорий с корнем в %WinDir%\WinSxS (традиционно: C:\Windows\WinSxS). Именование каталога выбрано от сокращения названия механизма Side-by-Side (Бок о бок), который обеспечивает одновременное существование в системе нескольких версий одноименной библиотеки. Из этого следует, что одним из предназначений технологии является устранение конфликтов между глобальными библиотеками DLL, установленными в операционной системе. В хранилище компонентов WinSxS каждый компонент помещается в свой подкаталог, определяемый собственным уникальным именем, которое включает в себя архитектуру процессора, имя компонента, уникальный идентификатор, версию компонента, язык локализации, для которых он был собран.

В системе компонент регистрируется под уникальным идентификатором.

По причине того, что теперь атомарной единицей при обновлении Windows является не файл, а компонент, при обновлении единственного файла выпускается новая версия всего компонента, в состав которого входит обновляемый файл. Различные версии компонентов носят название сборок - экземпляров определенной версии компонента, которые формируются при обновлении данного компонента. На практике это выглядит так: в процессе установки библиотеки, которая уже имеется в системе, конфликт обнаруживается, но файл библиотеки DLL не перезаписывается, а устанавливаемая версия помешается в папку WinSxS, при этом сохраняются соответствующие записи реестра, данных и прочее. Таким образом, наряду с новой версией компонента, в системе остаются и все старые его версии, призванные обеспечить штатное функционирование программного обеспечения, нуждающегося в строго определенной версии компонента. При этом, в системных местоположениях (например, в каталоге %WinDir%\System32) отображаются текущие версии системных библиотек, которые представляют собой жесткие ссылки, ведущие на оригиналы, размещаемые в хранилище компонентов с корнем в каталоге %WinDir%\WinSxS. Компоненты состоят из полезной нагрузки (различные системные файлы: библиотеки, исполняемые файлы, локальные файлы конфигурации и прочее) и манифеста (определяет зависимости).

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

Помимо компонентов, в системе присутствуют так называемые пакеты, которые могут представлять собой как отдельные автономные инсталляции (например: Internet Explorer Optional Package, Remote Desktop Service WinIP и прч.), содержащие системные приложения, так и исправления операционной системы (KB???????) и комплекты драйверов. Хранилище пакетов располагается в дереве директорий с корнем в %WinDir%\servicing\Packages. В хранилище пакетов каждый установленный пакет/обновление представлены двумя файлами: файлом каталога безопасности (.cat) и манифеста (.mum), определяется собственным уникальным именем, которое включает в себя архитектуру процессора, имя пакета, уникальный идентификатор, версию пакета, язык локализации, для которых он был собран. Остальные файлы пакета, похоже, размещаются в директории %WinDir%\WinSxS. Пакеты бывают установленными и подготовленными (к установке).

Манифест

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

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

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

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

По заявлению разработчиков, папка WinSxS является хранилищем разных версий общих библиотек и представляет собой "установочное и обслуживаемое состояние" всех системных компонентов.Теперь поговорим об обслуживании. Обслуживание системы в новых реалиях происходит уже на уровне компонентов. Даже технология носит название Обслуживание на основе компонентов (Component Based Servicing, CBS). Файлы поддержки технологии расположены в каталоге %SystemRoot%\servicing. В этом каталоге размещаются:

Наименование Описание
CbsApi.dll Основная библиотека поддержки технологии CBS.
CbsMsg.dll Дополнительная библиотека CBS.
TrustedInstaller.exe интерфейс между стеком обслуживания и разнообразными пользовательскими программами по обслуживанию, такими как sfc, dism, pkgmgr, оснасткой "Программы и компоненты", инсталляторами MSI, компонентом "Обновление Windows". Фактически, теперь только модуль TrustedInstaller.exe может модифицировать критические системные файлы. Скорее всего он просто вызывает функции из библиотек поддержки CBS, которые и занимаются актуальной работой.
wrpinitapi.dll Библиотека поддержки технологии Windows File Protection (WFP).
\Packages Хранилище пакетов. Подкаталог, который содержит файлы каталогов безопасности (.cat) и манифестов (.mum) установленных пакетов/обновлений. Сами пакеты/обновления, скорее всего, содержатся в директории %WinDir%\WinSxS;

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

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

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

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

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

Анализ результатов

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

Возможна ситуация, когда по причине некорректной работы сервиса обслуживания, файл отчетов CBS.log не успевает "ротироваться" и раздувается до немыслимых величин. На одной из систем я наблюдал аж 990Мб живых записей. Для открытия файла подобного объема придется постараться!

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

. . . 2015-12-23 15:25:51, Info CBS Starting TrustedInstaller initialization. 2015-12-23 15:25:51, Info CBS Loaded Servicing Stack v6.1.7601.18766 with Core: C:\Windows\winsxs\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_6.1.7601.18766_none_675144b3de10d6f7\cbscore.dll . . .

. . .

2015-12-23 15:25:51, Info       CBS    Starting TrustedInstaller initialization.

2015-12-23 15:25:51, Info       CBS    Loaded Servicing Stack v6.1.7601.18766 with Core: C:\Windows\winsxs\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_6.1.7601.18766_none_675144b3de10d6f7\cbscore.dll

. . .

Однако это еще не все, следующее неудобство в самостоятельном анализе результатов работы утилиты sfc заключается в том, что процесс, порожденный sfc, записывает в файл отчета в рамках нашей сессии довольно много лишней информацию обо всей активности WRP. Однако нам то необходимо найти информацию лишь об обнаруженных ошибках. Поэтому следующим шагом мы должны идентифицировать записи о интересующей нас сессии проверки утилиты sfc, для этого надо ориентироваться на указание в строках префикса восстановления [SR], располагающийся сразу после кода операции:

. . . 2015-12-23 15:39:06, Info CSI 000004c7 [SR] Repairing 1 components 2015-12-23 15:39:06, Info CSI 000004c8 [SR] Beginning Verify and Repair transaction 2015-12-23 15:39:06, Info CSI 000004c9 Hashes for file member \??\C:\Windows\Help\mui\0419\diskmgt.CHM do not match actual file [l:22{11}]"diskmgt.CHM" : Found: {l:32 b:JCNpg+LFxIGyUFtYwbXvF2R+9FWkC88/yc/Op2iiH8k=} Expected: {l:32 b:vXxHWLXn5gwsKgbK7zJa4TS12Iy3Df8EvJVVezXjfSw=} 2015-12-23 15:39:06, Info CSI 000004ca [SR] Repairing corrupted file [ml:520{260},l:56{28}]"\??\C:\Windows\Help\mui\0419"\[l:22{11}]"diskmgt.CHM" from store 2015-12-23 15:39:06, Info CSI 000004cb WARNING: File [l:22{11}]"diskmgt.CHM" in [l:56{28}]"\??\C:\Windows\Help\mui\0419" switching ownership Old: Server-Help-CHM.diskm_v.Resources, Version = 6.1.7600.16385, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture = [l:10{5}]"ru-RU", VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral New: Server-Help-CHM.diskmgt.Resources, Version = 6.1.7600.16385, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture = [l:10{5}]"ru-RU", VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral 2015-12-23 15:39:06, Info CSI 000004cc Repair results created: POQ 213 starts: 0: Move File: Source = [l:192{96}]"\SystemRoot\WinSxS\Temp\PendingRenames\b2b9dee97e3dd101ef5b0000a02be425._0000000000000000.cdf-ms", Destination = [l:104{52}]"\SystemRoot\WinSxS\FileMaps\_0000000000000000.cdf-ms" 1: Move File: Source = [l:162{81}]"\SystemRoot\WinSxS\Temp\PendingRenames\c3e0dee97e3dd101f05b0000a02be425.$$.cdf-ms", Destination = [l:74{37}]"\SystemRoot\WinSxS\FileMaps\$$.cdf-ms" 2: Move File: Source = [l:224{112}]"\SystemRoot\WinSxS\Temp\PendingRenames\8fb5e0e97e3dd101f15b0000a02be425.$$_help_mui_0419_c7942096fabea648.cdf-ms", Destination = [l:136{68}]"\SystemRoot\WinSxS\FileMaps\$$_help_mui_0419_c7942096fabea648.cdf-ms" 3: Hard Link File: Source = [l:250{125}]"\SystemRoot\WinSxS\amd64_server-help-chm.diskmgt.resources_31bf3856ad364e35_6.1.7600.16385_ru-ru_6242fb22a9e1a289\diskmgt.CHM", Destination = [l:80{40}]"\??\C:\Windows\Help\mui\0419\diskmgt.CHM" POQ 213 ends. 2015-12-23 15:39:06, Info CSI 000004cd [SR] Repair complete . . .

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

. . .

2015-12-23 15:39:06, Info      CSI    000004c7 [SR] Repairing 1 components

2015-12-23 15:39:06, Info      CSI    000004c8 [SR] Beginning Verify and Repair transaction

2015-12-23 15:39:06, Info      CSI    000004c9 Hashes for file member \??\C:\Windows\Help\mui\0419\diskmgt.CHM do not match actual file [l:22{11}]"diskmgt.CHM" :

  Found: {l:32 b:JCNpg+LFxIGyUFtYwbXvF2R+9FWkC88/yc/Op2iiH8k=} Expected: {l:32 b:vXxHWLXn5gwsKgbK7zJa4TS12Iy3Df8EvJVVezXjfSw=}

2015-12-23 15:39:06, Info      CSI    000004ca [SR] Repairing corrupted file [ml:520{260},l:56{28}]"\??\C:\Windows\Help\mui\0419"\[l:22{11}]"diskmgt.CHM" from store

2015-12-23 15:39:06, Info      CSI    000004cb WARNING: File [l:22{11}]"diskmgt.CHM" in [l:56{28}]"\??\C:\Windows\Help\mui\0419" switching ownership

    Old: Server-Help-CHM.diskm_v.Resources, Version = 6.1.7600.16385, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture = [l:10{5}]"ru-RU", VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral

    New: Server-Help-CHM.diskmgt.Resources, Version = 6.1.7600.16385, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture = [l:10{5}]"ru-RU", VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral

2015-12-23 15:39:06, Info      CSI    000004cc Repair results created:

POQ 213 starts:

     0: Move File: Source = [l:192{96}]"\SystemRoot\WinSxS\Temp\PendingRenames\b2b9dee97e3dd101ef5b0000a02be425._0000000000000000.cdf-ms", Destination = [l:104{52}]"\SystemRoot\WinSxS\FileMaps\_0000000000000000.cdf-ms"

    1: Move File: Source = [l:162{81}]"\SystemRoot\WinSxS\Temp\PendingRenames\c3e0dee97e3dd101f05b0000a02be425.$$.cdf-ms", Destination = [l:74{37}]"\SystemRoot\WinSxS\FileMaps\$$.cdf-ms"

    2: Move File: Source = [l:224{112}]"\SystemRoot\WinSxS\Temp\PendingRenames\8fb5e0e97e3dd101f15b0000a02be425.$$_help_mui_0419_c7942096fabea648.cdf-ms", Destination = [l:136{68}]"\SystemRoot\WinSxS\FileMaps\$$_help_mui_0419_c7942096fabea648.cdf-ms"

    3: Hard Link File: Source = [l:250{125}]"\SystemRoot\WinSxS\amd64_server-help-chm.diskmgt.resources_31bf3856ad364e35_6.1.7600.16385_ru-ru_6242fb22a9e1a289\diskmgt.CHM", Destination = [l:80{40}]"\??\C:\Windows\Help\mui\0419\diskmgt.CHM"

POQ 213 ends.

2015-12-23 15:39:06, Info      CSI    000004cd [SR] Repair complete

. . .

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

<дата> <время>, Info CSI xxxxxxxx [SR] Repairing XX components . . . <дата> <время>, Info CSI xxxxxxxx [SR] Repair complete

<дата> <время>, Info      CSI    xxxxxxxx [SR] Repairing XX components

. . .

<дата> <время>, Info      CSI    xxxxxxxx [SR] Repair complete

, во втором содержится информация по проверке компонентов и границы блоков помечаются так:

<дата> <время>, Info CSI xxxxxxxx [SR] Verifying XX components . . . <дата> <время>, Info CSI xxxxxxxx [SR] Verify complete

<дата> <время>, Info      CSI    xxxxxxxx [SR] Verifying XX components

. . .

<дата> <время>, Info      CSI    xxxxxxxx [SR] Verify complete

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

findstr /c:"[SR]" %windir%\logs\cbs\cbs.log > c:\sfcdetails.txt

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

Ручное восстановление файлов

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

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

Для этого выполните следующую команду:

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

Например:

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

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

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

Например:

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

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

copy e:\temp\svchost.exe c:\windows\system32\svchost.exe

Или выполнить перемещение файла с одного местоположение в другое с помощью проводника Windows.

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

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

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

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

dism /Online /Cleanup-Image /RestoreHealth

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

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

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

. . . 2016-01-05 14:20:31, Info CSI 00001a68 [SR] Verifying 100 (0x0000000000000064) components 2016-01-05 14:20:31, Info CSI 00001a69 [SR] Beginning Verify and Repair transaction 2016-01-05 14:20:31, Info CSI 00001a6a [SR] Cannot repair member file [l:32{16}]"BRCI06UI.DLL.mui" of prnbr002.inf.Resources, Version = 6.1.7600.16385, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture = [l:10{5}]"ru-RU", VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, file is missing 2016-01-05 14:20:31, Info CSI 00001a6b [SR] Cannot repair member file [l:32{16}]"prnbr002.inf_loc" of prnbr002.inf.Resources, Version = 6.1.7600.16385, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture = [l:10{5}]"ru-RU", VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, file is missing 2016-01-05 14:20:31, Error CSI 00001a6c (F) STATUS_OBJECT_NAME_NOT_FOUND #28089837# from Windows::Rtl::SystemImplementation::DirectFileSystemProvider::SysCreateFile(flags = (AllowSharingViolation), handle = {provider=NULL, handle=0}, da = (SYNCHRONIZE|FILE_READ_ATTRIBUTES), oa = @0x195c7d0->OBJECT_ATTRIBUTES {s:48; rd:NULL; on:[100]"\??\C:\Windows\WinSxS\amd64_prnbr002.inf_31bf3856ad364e35_6.1.7600.16385_none_49c93aa2c4304e9e\Amd64"; a:(OBJ_CASE_INSENSITIVE)}, iosb = @0x195c7b0, as = (null), fa = 0, sa = (FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE), cd = FILE_OPEN, co = (FILE_SYNCHRONOUS_IO_NONALERT|0x00004000), eab = NULL, eal = 0, disp = Invalid) 2016-01-05 14:20:31, Error CSI [email protected]/1/5:10:20:31.885 (F) d:\win7sp1_gdr\base\wcp\sil\merged\ntu\ntsystem.cpp(2057): Error STATUS_OBJECT_NAME_NOT_FOUND originated in function Windows::Rtl::SystemImplementation::DirectFileSystemProvider::SysCreateFile expression: (null) 2016-01-05 14:20:31, Error CSI 00001a6e (F) STATUS_OBJECT_NAME_NOT_FOUND #28089836# from Windows::Rtl::SystemImplementation::CDirectory::OpenExistingDirectory(...)[gle=0xd0000034] 2016-01-05 14:20:31, Error CSI 00001a6f (F) STATUS_OBJECT_NAME_NOT_FOUND #28089835# from Windows::Rtl::SystemImplementation::CDirectory_IRtlDirectoryTearoff::OpenExistingDirectory(flags = 0, da = (SYNCHRONIZE), oa = @0x195d0e0->SIL_OBJECT_ATTRIBUTES {s:40; on:"Amd64"; a:(OBJ_CASE_INSENSITIVE)}, sa = (FILE_SHARE_READ|FILE_SHARE_WRITE), oo = (FILE_DIRECTORY_FILE|FILE_SYNCHRONOUS_IO_NONALERT|FILE_OPEN_FOR_BACKUP_INTENT), dir = NULL, disp = (null)) . . .

. . .

2016-01-05 14:20:31, Info                  CSI    00001a68 [SR] Verifying 100 (0x0000000000000064) components

2016-01-05 14:20:31, Info                  CSI    00001a69 [SR] Beginning Verify and Repair transaction

2016-01-05 14:20:31, Info                  CSI    00001a6a [SR] Cannot repair member file [l:32{16}]"BRCI06UI.DLL.mui" of prnbr002.inf.Resources, Version = 6.1.7600.16385, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture = [l:10{5}]"ru-RU", VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, file is missing

2016-01-05 14:20:31, Info                  CSI    00001a6b [SR] Cannot repair member file [l:32{16}]"prnbr002.inf_loc" of prnbr002.inf.Resources, Version = 6.1.7600.16385, pA = PROCESSOR_ARCHITECTURE_AMD64 (9), Culture = [l:10{5}]"ru-RU", VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, file is missing

2016-01-05 14:20:31, Error                 CSI    00001a6c (F) STATUS_OBJECT_NAME_NOT_FOUND #28089837# from Windows::Rtl::SystemImplementation::DirectFileSystemProvider::SysCreateFile(flags = (AllowSharingViolation), handle = {provider=NULL, handle=0}, da = (SYNCHRONIZE|FILE_READ_ATTRIBUTES), oa = @0x195c7d0->OBJECT_ATTRIBUTES {s:48; rd:NULL; on:[100]"\??\C:\Windows\WinSxS\amd64_prnbr002.inf_31bf3856ad364e35_6.1.7600.16385_none_49c93aa2c4304e9e\Amd64"; a:(OBJ_CASE_INSENSITIVE)}, iosb = @0x195c7b0, as = (null), fa = 0, sa = (FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE), cd = FILE_OPEN, co = (FILE_SYNCHRONOUS_IO_NONALERT|0x00004000), eab = NULL, eal = 0, disp = Invalid)

2016-01-05 14:20:31, Error                 CSI    [email protected]/1/5:10:20:31.885 (F) d:\win7sp1_gdr\base\wcp\sil\merged\ntu\ntsystem.cpp(2057): Error STATUS_OBJECT_NAME_NOT_FOUND originated in function Windows::Rtl::SystemImplementation::DirectFileSystemProvider::SysCreateFile expression: (null)

2016-01-05 14:20:31, Error                 CSI    00001a6e (F) STATUS_OBJECT_NAME_NOT_FOUND #28089836# from Windows::Rtl::SystemImplementation::CDirectory::OpenExistingDirectory(...)[gle=0xd0000034]

2016-01-05 14:20:31, Error                 CSI    00001a6f (F) STATUS_OBJECT_NAME_NOT_FOUND #28089835# from Windows::Rtl::SystemImplementation::CDirectory_IRtlDirectoryTearoff::OpenExistingDirectory(flags = 0, da = (SYNCHRONIZE), oa = @0x195d0e0->SIL_OBJECT_ATTRIBUTES {s:40; on:"Amd64"; a:(OBJ_CASE_INSENSITIVE)}, sa = (FILE_SHARE_READ|FILE_SHARE_WRITE), oo = (FILE_DIRECTORY_FILE|FILE_SYNCHRONOUS_IO_NONALERT|FILE_OPEN_FOR_BACKUP_INTENT), dir = NULL, disp = (null))

. . .

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

. . . 2016-10-25 09:15:30, Info CSI 0000041a Hashes for file member \SystemRoot\WinSxS\amd64_microsoft-desktop-p..ioning-platform-uap_31bf3856ad364e35_10.0.14931.1000_none_e868e65d27732283\Microsoft-Desktop-Provisioning-Sequence.dat do not match actual file [l:43]'Microsoft-Desktop-Provisioning-Sequence.dat' : Found: {l:32 P4BBQawQJIz/P7ly39QB9lUblePLIsLBlQTcZE7gCvk=} Expected: {l:32 5aaD6vcrN1P+4LUm/1TfSOGQ6/t3GihLoGaPPkYDGdE=} 2016-10-25 09:15:30, Info CSI 0000041b [SR] Cannot repair member file [l:43]'Microsoft-Desktop-Provisioning-Sequence.dat' of Microsoft-Desktop-Provisioning-Platform-Uap, version 10.0.14931.1000, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35} in the store, hash mismatch 2016-10-25 09:15:30, Info CSI 0000041c [SR] This component was referenced by [l:178]'Microsoft-Windows-Client-Features-Package-AutoMerged-onecoreuap~31bf3856ad364e35~amd64~~10.0.14931.1000.Microsoft-Windows-Client-Features-Package-AutoMerged-onecoreuap-Deployment' 2016-10-25 09:15:30, Info CSI 0000041d Hashes for file member \??\C:\WINDOWS\Provisioning\Microsoft-Desktop-Provisioning-Sequence.dat do not match actual file [l:43]'Microsoft-Desktop-Provisioning-Sequence.dat' : Found: {l:32 P4BBQawQJIz/P7ly39QB9lUblePLIsLBlQTcZE7gCvk=} Expected: {l:32 5aaD6vcrN1P+4LUm/1TfSOGQ6/t3GihLoGaPPkYDGdE=} 2016-10-25 09:15:30, Info CSI 0000041e Hashes for file member \SystemRoot\WinSxS\amd64_microsoft-desktop-p..ioning-platform-uap_31bf3856ad364e35_10.0.14931.1000_none_e868e65d27732283\Microsoft-Desktop-Provisioning-Sequence.dat do not match actual file [l:43]'Microsoft-Desktop-Provisioning-Sequence.dat' : Found: {l:32 P4BBQawQJIz/P7ly39QB9lUblePLIsLBlQTcZE7gCvk=} Expected: {l:32 5aaD6vcrN1P+4LUm/1TfSOGQ6/t3GihLoGaPPkYDGdE=} 2016-10-25 09:15:30, Info CSI 0000041f [SR] Could not reproject corrupted file \??\C:\WINDOWS\Provisioning\Microsoft-Desktop-Provisioning-Sequence.dat; source file in store is also corrupted . . .

. . .

2016-10-25 09:15:30, Info                  CSI    0000041a Hashes for file member \SystemRoot\WinSxS\amd64_microsoft-desktop-p..ioning-platform-uap_31bf3856ad364e35_10.0.14931.1000_none_e868e65d27732283\Microsoft-Desktop-Provisioning-Sequence.dat do not match actual file [l:43]'Microsoft-Desktop-Provisioning-Sequence.dat' : Found: {l:32 P4BBQawQJIz/P7ly39QB9lUblePLIsLBlQTcZE7gCvk=} Expected: {l:32 5aaD6vcrN1P+4LUm/1TfSOGQ6/t3GihLoGaPPkYDGdE=}

2016-10-25 09:15:30, Info                  CSI    0000041b [SR] Cannot repair member file [l:43]'Microsoft-Desktop-Provisioning-Sequence.dat' of Microsoft-Desktop-Provisioning-Platform-Uap, version 10.0.14931.1000, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35} in the store, hash mismatch

2016-10-25 09:15:30, Info                  CSI    0000041c [SR] This component was referenced by [l:178]'Microsoft-Windows-Client-Features-Package-AutoMerged-onecoreuap~31bf3856ad364e35~amd64~~10.0.14931.1000.Microsoft-Windows-Client-Features-Package-AutoMerged-onecoreuap-Deployment'

2016-10-25 09:15:30, Info                  CSI    0000041d Hashes for file member \??\C:\WINDOWS\Provisioning\Microsoft-Desktop-Provisioning-Sequence.dat do not match actual file [l:43]'Microsoft-Desktop-Provisioning-Sequence.dat' : Found: {l:32 P4BBQawQJIz/P7ly39QB9lUblePLIsLBlQTcZE7gCvk=} Expected: {l:32 5aaD6vcrN1P+4LUm/1TfSOGQ6/t3GihLoGaPPkYDGdE=}

2016-10-25 09:15:30, Info                  CSI    0000041e Hashes for file member \SystemRoot\WinSxS\amd64_microsoft-desktop-p..ioning-platform-uap_31bf3856ad364e35_10.0.14931.1000_none_e868e65d27732283\Microsoft-Desktop-Provisioning-Sequence.dat do not match actual file [l:43]'Microsoft-Desktop-Provisioning-Sequence.dat' : Found: {l:32 P4BBQawQJIz/P7ly39QB9lUblePLIsLBlQTcZE7gCvk=} Expected: {l:32 5aaD6vcrN1P+4LUm/1TfSOGQ6/t3GihLoGaPPkYDGdE=}

2016-10-25 09:15:30, Info                  CSI    0000041f [SR] Could not reproject corrupted file \??\C:\WINDOWS\Provisioning\Microsoft-Desktop-Provisioning-Sequence.dat; source file in store is also corrupted

. . .

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

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

Запуск из среды восстановления

Если сама операционная система уже не в состоянии загрузиться в штатном режиме, можно запустить sfc из командной строки консоли восстановления. Для запуска консоли восстановления перезагрузите компьютер и после вывода статусных сообщений BIOS/UEFI нажмите несколько раз клавишу F8. В появившемся меню выбираем пункт "Устранение неполадок компьютера". Далее, после нескольких окон выбора языка и авторизации, в финальном меню выбираем пункт "Командная строка".

sfc windows re console

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

sfc /scannow /offbootdir=d:\ /offwindir=d:\windows

После запуска стартует процесс проверки, который может продолжаться довольно длительное время

sfc offbootdir offwindir

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

Выводы

Очевидно, что утилита sfc не является панацеей от всех видов проблем, возникающих в операционной системе Windows. Нередки случаи, когда sfc не может найти никаких повреждений в системных компонентах, или же находит и устраняет их, однако ошибки возникают вновь. Подобное поведение намекает на то, что сам механизм компонентов в операционной системе Windows довольно "сырой" и находится в перманентной "бете", о чем разработчики предпочитают молчать, просто поддерживая его в более-менее работоспособном состоянии и дорабатывая по мере своих возможностей от версии к версии. Эта догадка подтверждается большим количеством ошибок, которые невозможно исправить автоматизированными системными средствами. В этом случае, как и в случае, когда утилита sfc не обнаружила в системе поврежденных компонентов, при сохранении тенденции к нестабильной работе системы стоит рассмотреть иные способы диагностики.

datadump.ru


Смотрите также