В процессе эксплуатации операционной системы Windows, периодически возникает необходимость установки/удаления различного рода программного обеспечения. Вы прекрасно представляете, что программное обеспечение достаточно многообразно и порой довольно сложно оценить степень его влияния на систему, одни программы являются достаточно безобидными, другие же могут вносить в систему настолько существенные изменения, что в пору говорить о полноценном системном обновлении. С другой стороны, невозможно полностью исключить ситуации с установкой в систему заведомо устаревших модулей, частично потерявших совместимость с текущей версией Windows. К тому же, если эксплуатационный цикл системы довольно продолжителен, то в процессе установки/удаления/замены различных обновлений и стороннего ПО можно говорить о накоплении (либо удалении) различных версий системных библиотек, всевозможных модификаций ключевых системных структур (реестра, библиотек, исполняемых модулей). Помимо этого, достаточно важные компоненты операционной системы могут повреждаться, либо удаляться вовсе в следствии деятельности вредоносного программного обеспечения (вирусы, трояны). Во всем многообразии этого броуновского движения, крайне сложно спрогнозировать последствия подобных изменений системы, они могут оставаться определенное время незамеченными либо вовсе никогда не проявить себя, однако чаще всего случается так, что спустя некоторое время мы начинаем наблюдать довольно таки интересные "нештатные ситуации", в которых операционная система, в самом прямом смысле, ведет себя довольно странно.
Проблема сохранения работоспособности ключевых системных компонентов и, как следствие, операционной системы в целом, стояла перед разработчиками Microsoft Windows с самого того дня, когда первые версии ОС начинали своё знакомство с широкой аудиторией, ведь по началу сама система была и вовсе беззащитна от вмешательства различного рода стороннего программного обеспечения, инсталлируемого с использованием административных привилегий и беззастенчиво переписывающего своими компонентами "родные" системные модули. Понятно, что столь серьезная проблема требовала своего скорейшего решения и в итоге Microsoft начали предоставлять изнемогающей от глюков общественности различные методы решения проблемы. Это были, по-началу, и службы контроля за целостностью важных системных файлов, и утилиты привидения их к эталонным версиям, в конечном итоге был разработан принцип компонентизации или модуляризации. "-Ну Конечно",- скажете Вы,- "зачем нам все это? Ведь мы всегда можем решить проблему и более кардинальным образом, ведь у нас в запасе есть проверенное десятилетиями, безотказное средство под названием "переустановка", либо такое как возврат к ранее созданной точке восстановления". Можно восстановить из ранее созданного образа системы, но этим могут похвастаться лишь самые педантичные, а у обычных технических обывателей, таких как мы с Вами, довольно редко резервный образ бывает актуальным (если вообще присутствует), в любом случае, придется затратить свое драгоценное личное время на приведение системы к необходимому актуальному состоянию. Эти методы действительно актуальны, однако подобное решение и так рассматривалось разработчиками как выход из сложившейся ситуации довольно продолжительное время :) Все это не делает систему стабильнее, а ведь одна из задач авторов хорошей ОСи - сделать её отказоустойчивой. Сейчас всё вышло на новый уровень, разработчики Microsoft представили средство под названием sfc, о котором и пойдет речь в данной статье.
В общем случае, утилита выполняет сканирование и восстановление поврежденных или отсутствующих системных файлов путем сравнения экземпляра, установленного в системе с эталонной версией, размещенной в специализированном защищенном хранилище системных компонентов.
Запуск проверки целостности файлов
Поскольку sfc является консольной утилитой (утилитой командной строки), то и запускать её следует из командного интерпретатора cmd. Для выполнения комплексной проверки всех системных файлов, выполните следующую команду:
sfc /scannow
Утилита стартует процесс проверки системных файлов, в ходе которого будут заменяться/восстанавливаться поврежденные/отсутствующие файлы. Теперь оставьте окно в покое и дождитесь окончания процесса проверки.
Естественно что утилита 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, однако имейте в виду, что в этом случае возможны некоторые нюансы :)
Алгоритм работы
С целью дальнейшего решения проблемы совместимости конкретного приложения и DLL, в версиях систем Microsoft, начиная с Windows Vista, произошел отход от традиционной модели обновления системных файлов (библиотек, исполняемых модулей и прч.) и была введена концепция тиражирования компонентов (или общих сборок, см. далее). В более ранних версиях операционных систем обновлялись непосредственно системные файлы, при этом старые версии которых безвозвратно удалялись, тем самым часто вызывая проблемы в работе определенных программ (проблемы совместимости).
.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;
С другой стороны, любое приложение системы, желающее использовать строго определенные сборки компонентов, должно непосредственно указывать идентификаторы этих сборок в специальном файле, так же носящем название манифест. Манифест приложения определяет зависимости, которые использует приложение и связывает его со строго определенной версией компонента. Другими словами, приложение связывается с конкретным компонентом (сборкой) посредством собственного XML-файла (манифеста).
По структуре манифест приложения может представлять собой:
- отдельный файл, размещаемый в директории приложения;
- ресурс (блок данных), включенный в исполняемый файл приложения (располагается в ресурсной секции исполняемого файла);
Обслуживание
По заявлению разработчиков, папка 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)).
Сам принцип защиты критических файлов так же поменялся со времен WFP, теперь отсутствует системный процесс, который в реальном времени следит за попытками модификации критических файлов, а система ограничивает доступ к важным системным файлам при помощи списков контроля доступа (DACL/ACL), то есть 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. Дата и время фигурируют в файле в каждой записи в первых двух параметрах:
|
1 2 3 4 |
. . . 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], располагающийся сразу после кода операции:
|
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 . . . |
Кроме того, стоит учитывать тот факт, что информация в файле отчета группируется в своеобразные контейнеры, представляющие из себя группу записей по устранению какой-либо проблемы либо группу родственных проблем. Судя по всему, применяется два основных типа контейнеров. В первом из них содержится информация по восстановлению компонентов и границы блоков помечаются как:
|
1 2 3 |
<дата> <время>, Info CSI xxxxxxxx [SR] Repairing XX components . . . <дата> <время>, Info CSI xxxxxxxx [SR] Repair complete |
, во втором содержится информация по проверке компонентов и границы блоков помечаются так:
|
1 2 3 |
<дата> <время>, 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 полный_путь_к файлу\имя_файла
Например:
Далее, дать текущей учетной записи полный доступ к поврежденному файлу.
Для этого выполните следующую команду:
icacls полный_путь_к файлу\имя_файла /GRANT АДМИНИСТРАТОРЫ:F
Например:
И уже в финальной части, можно наконец-то скопировать работоспособную копию восстанавливаемого файла на место поврежденного (например, если у нас нормальный файл располагается на флешке, обозначенной в системе буквой 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 можно обнаружить сообщения, подобные этим:
|
1 2 3 4 5 6 7 8 9 10 |
. . . 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 00001a6d@2016/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. Заглянув в целевой каталог, я убедился, что он действительно пуст, а вот что за событие уничтожило его содержимое, остается только гадать. Проверив аналогичный каталог на нормально-функционирующей системе, я обнаружил там необходимые нам файлы и каталоги и в целях восстановления хранилища на поврежденной системе, скопировал все содержимое каталога, перед этим, правда, установив необходимые разрешения для локального администратора на описанный выше целевой каталог (иначе система не дает записать информацию).
Встречаются, так же, случаи повреждения файлов в хранилище, которые связаны с несовпадением контрольной суммы файлов:
|
1 2 3 4 5 6 7 8 |
. . . 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 и литеру загрузочного диска:
sfc /scannow /offbootdir=d:\ /offwindir=d:\windows
После запуска стартует процесс проверки, который может продолжаться довольно длительное время
Для чего нам конкретизировать системный том параметром offbootdir? Вероятно, как раз на основании этого параметра высчитывается путь к папке хранилища WinSxS и реестра, содержащей сами эталонные файлы и записи о регистрации компонентов.
Выводы
Очевидно, что утилита sfc не является панацеей от всех видов проблем, возникающих в операционной системе Windows. Нередки случаи, когда sfc не может найти никаких повреждений в системных компонентах, или же находит и устраняет их, однако ошибки возникают вновь. Подобное поведение намекает на то, что сам механизм компонентов в операционной системе Windows довольно "сырой" и находится в перманентной "бете", о чем разработчики предпочитают молчать, просто поддерживая его в более-менее работоспособном состоянии и дорабатывая по мере своих возможностей от версии к версии. Эта догадка подтверждается большим количеством ошибок, которые невозможно исправить автоматизированными системными средствами. В этом случае, как и в случае, когда утилита sfc не обнаружила в системе поврежденных компонентов, при сохранении тенденции к нестабильной работе системы стоит рассмотреть иные способы диагностики.
Как всегда - глубоко, подробно и, что важно, понятно. Спасибо и с Новым Годом!
с Новым годом! :)
Что делать, если Windows 10 не грузится (зависает на экране загрузке при попытке автоматического восстановления системы), а при загрузке с установочной флешки Windows 10 и запуске из командной строки sfc /scannow выдается надпись "Защите ресурсов Windows не удалось выполнить запрошенную операцию"?
В логе проверки sfc огромное количество ошибок, в основном то что у папок в system32 оказалось больше одного владельца.
При попытке восстановить систему, переустановив ее поверх, Windows 10 предлагает перезагрузиться и повторить попытку непосредственно из системы. Великолепно.
Интересная ошибка. Попробуйте пропустить ошибки владельца файлов и сосредоточиться именно на ошибках восстановления системных файлов и устранить эти ошибки вручную, друг за другом.