Windows 7 logs cbs как очистить

Компонентное обслуживание (cbs.log) может начать использовать все пространство на диске, если системные файлы повреждены или если обновление Windows постоянно

Компонентное обслуживание (cbs.log) может начать использовать все пространство на диске, если системные файлы повреждены или если обновление Windows постоянно не устанавливается. Проблема возникает, когда пользователь видит, что его системный диск заполнен (или большая часть диска занята) журналами CBS. Но после удаления файлов журналы снова стремительно увеличиваются в размерах.

Компонентное обслуживание (cbs.log) приводит к использованию всего дискового пространства

Прежде чем переходить к уменьшению размера журнала CBS, обязательно сбросьте ассоциацию файлов на значения по умолчанию (Настройки> Приложения> Приложения по умолчанию> Сбросить до рекомендованных Microsoft значений по умолчанию).

Сброс до рекомендованных Microsoft значений по умолчанию

Файлы журнала CBS разделяются на разные файлы, когда размер файла достигает 50 МБ, а затем сжимаются для экономии места на диске. Но проблема возникает, когда размер файла журнала CBS (из-за сбоя) увеличивается до 2 ГБ (после чего Makecab не может его сжать), и размер файла начинает быстро расти. В этом контексте удаление файлов CBS может решить проблему.

  1. Щелкните Windows, введите: Services и щелкните его правой кнопкой мыши. Затем выберите Запуск от имени администратора.Открыть сервисы в качестве администратора
  2. Теперь щелкните правой кнопкой мыши службу Центра обновления Windows и в появившемся меню выберите Остановить.Остановите службу обновления Windows
  3. Затем повторите то же самое, чтобы остановить службу установщика модулей Windows (если вы не можете отключить службу установщика модулей Windows, попробуйте метод, упомянутый в конце этого решения).Остановите службу установщика модулей Windows
  4. Затем щелкните правой кнопкой мыши Windows и выберите Диспетчер задач.
  5. Теперь щелкните правой кнопкой мыши установщик модулей Windows (если он есть) и выберите «Завершить задачу».
  6. Затем перейдите на вкладку «Подробности» и щелкните правой кнопкой мыши файл TiWorker.exe.Завершите задачу TiWorker.Exe и TrustedInstaller на вкладке Details
  7. Теперь выберите «Завершить задачу», а затем завершите задачу TrustedInstaller.exe на вкладке «Подробности».
  8. Затем перейдите по следующему пути (скопируйте и вставьте адрес): Windows Logs CBSУдалить журналы CBS
  9. Теперь удалите все файлы в папке CBS и перейдите в следующую временную папку: windows temp Удалите содержимое временной папки Windows
  10. Затем удалите все файлы в папке Temp (возможно, вам придется стать владельцем некоторых файлов), а после этого не забудьте очистить корзину.
  11. Теперь запустите установщик модулей Windows и службу Windows Update (шаги с 1 по 3).
  12. Затем снова проверьте временную папку Windows (шаг 9) и, если она показывает какие-либо файлы, также удалите эти файлы.
  13. Теперь снова очистите корзину и выключите компьютер.
  14. Подождите одну минуту, а затем включите систему.
  15. После загрузки системы проверьте, решена ли проблема CBS.log.

Если вы не можете остановить установщик модулей Windows, попробуйте следующий метод:

  1. Щелкните Windows, введите: Командная строка, щелкните правой кнопкой мыши Командную строку и выберите Запуск от имени администратора.Откройте командную строку от имени администратора
  2. Теперь выполните следующее: net stop TrustedInstallerОстановите службу TrustedInstaller через командную строку
  3. В случае успеха попробуйте выполнить шаги 4-15, чтобы удалить CBS.log, а если вышеприведенная команда не удалась, выполните следующие действия один за другим: sc qc TrustedInstaller tasklist | найти / i «TrustedInstaller.exe» taskkill / f / im «TrustedInstaller.exe»Завершите TrustedInstaller.Exe через диспетчер задач.
  4. Затем попробуйте выполнить шаги 4–15, чтобы удалить файлы CBS.log, и проверьте, решает ли это проблему с местом на диске.

Решение 2. Выполните сканирование SFC

Проблема CBS.log может возникнуть, если основные системные файлы повреждены. В этом контексте выполнение сканирования SFC может устранить повреждение файлов и, таким образом, решить проблему.

  1. Во-первых, выключите компьютер и подождите одну минуту.
  2. Затем включите систему и выполните сканирование SFC.Выполните сканирование SFC
  3. После завершения сканирования проверьте, вернулся ли CBS.log к нормальному размеру. Если нет, то удалите CBS.log (как описано в решении 1) и проверьте, решает ли это проблему обслуживания баз компонентов.

Решение 3. Выполните автономное обновление вручную

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

  1. Щелкните правой кнопкой мыши Windows и откройте «Настройки».
  2. Теперь выберите «Обновление и безопасность» и на правой панели откройте «Дополнительные параметры».Открыть обновление и безопасность
  3. Затем разверните раскрывающийся список «Приостановить обновления» и выберите дату.Открыть дополнительные параметры обновления
  4. Теперь убедитесь, что все приложения полностью закрыты (чтобы ни одно приложение не записывалось на системный накопитель), и нажимайте кнопку питания, пока система не выключится (не выключайте и не перезапускайте). Затем включите систему.Приостановить обновления Windows
  5. После загрузки системы запустите веб-браузер и откройте Страница загрузки Windows 10 веб-сайта Microsoft.
  6. Теперь нажмите кнопку «Обновить сейчас» для получения последнего обновления (например, Windows 10 October 2020 Update) и дождитесь завершения загрузки.Нажмите «Обновить сейчас» на странице загрузки Windows 10.
  7. Затем запустите загруженный файл от имени администратора и следуйте инструкциям по установке обновления.
  8. После завершения установки перезагрузите компьютер и после перезагрузки перейдите к Каталог Центра обновления Майкрософт.Найдите и загрузите последнее обновление базы знаний с веб-сайта каталога обновлений
  9. Теперь загрузите последние обновления базы знаний для своей системы (вы можете поискать в Интернете номера базы знаний последних обновлений для вашей системы).
  10. Затем установите обновление от имени администратора, следуя подсказкам для завершения установки.
  11. Теперь перезагрузите компьютер и удалите CBS.log (как описано в решении 1).
  12. Затем отключите параметр паузы обновления (повторив шаги с 1 по 3) и проверьте, решена ли проблема с диском CBS.

Решение 4.Используйте планировщик задач для удаления файлов журнала CBS

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

  1. Щелкните Windows, введите: Блокнот и откройте его.
  2. Теперь скопируйте и вставьте в Блокнот следующие строки: net stop «TrustedInstaller» del / S c: windows logs cbs *. Log net start «TrustedInstaller»Создайте пакетный файл для удаления журналов CBS
  3. Затем разверните меню «Файл» и выберите «Сохранить».
  4. Теперь измените тип файла на «Все файлы» и назовите файл с расширением .bat (например, DeleteCBSLog.bat).Сохраните пакетный файл
  5. После этого в диалоговом окне «Сохранить как» перейдите в каталог, в котором вы хотите сохранить файл (например, «Рабочий стол»).
  6. Теперь нажмите «Сохранить» и закройте Блокнот.
  7. Теперь щелкните Windows, введите: Планировщик заданий и откройте его.Откройте планировщик заданий
  8. Затем разверните меню «Действие» и выберите «Создать задачу».Создать задачу в планировщике задач
  9. Теперь введите имя задачи (например, DeleteCBSLogs) и установите флажок «Запускать с высшими привилегиями».Создайте задачу удаления журнала CBS в планировщике задач
  10. Затем перейдите на вкладку «Триггеры» и нажмите кнопку «Создать».Создать новый триггер для задачи
  11. Теперь выберите «Ежедневно» и нажмите кнопку «ОК».Установите новый триггер на ежедневный
  12. Затем перейдите на вкладку «Действия» и нажмите кнопку «Создать».Создать новое действие в планировщике задач
  13. Теперь нажмите «Обзор» (перед «Программа / сценарий») и перейдите в каталог, в котором находится файл .bat (например, «Рабочий стол»).Нажмите кнопку «Обзор» в окне «Новое действие».
  14. Затем дважды щелкните пакетный файл (например, DeleteCBSLogs) и перейдите на вкладку «Настройки».Дважды щелкните пакетный файл.
  15. Теперь отметьте «Если задача не удалась, перезапускать каждые» и установите в раскрывающемся списке значение 1 час.
  16. Затем снимите флажок «Остановить задачу, если она выполняется дольше, чем» и нажмите кнопку «ОК».Установите флажок «Сбой задачи» и снимите флажок «Остановить задачу» в планировщике задач.
  17. Теперь удалите журналы CBS (как описано в решении 1) и перезагрузите устройство, чтобы проверить, решена ли проблема CBS.log.

Решение 5. Отредактируйте системный реестр, чтобы остановить создание файлов журнала CBS.

Если ни одно из решений не помогло вам, то редактирование системного реестра для отключения журнала CBS может решить проблему (не забудьте включить этот параметр после того, как проблема будет решена).

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

  1. Щелкните Windows, введите: Редактор реестра и щелкните его правой кнопкой мыши. Затем выберите Запуск от имени администратора.
  2. Теперь перейдите по следующему пути: Computer HKEY_LOCAL_MACHINE SOFTWARE Microsoft Windows CurrentVersion Component Based Servicing.
  3. Затем дважды щелкните EnableLog и установите для него значение 0 (возможно, вам придется стать владельцем раздела реестра).Установите для EnableLog значение 0
  4. Теперь выйдите из редактора и удалите текущие журналы CBS, как описано в решении 1.
  5. Затем перезагрузите компьютер и проверьте, решена ли проблема CBS.log.

Если проблема не исчезнет, ​​вы можете попробовать стороннюю утилиту для очистки, чтобы проверить, устраняет ли она проблему CBS.log.

Источник

На чтение 6 мин. Просмотров 85 Опубликовано 13.04.2021

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

Об этой конкретной проблеме часто сообщают в Windows 7, Windows 8 и Windows 10. В некоторых случаях Системный файл отчетов об ошибках Windows поставлен в очередь имеет размер более 200 ГБ.

Содержание

  1. Что такое Windows с системной очередью Файлы отчетов об ошибках?
  2. Что вызывает очередь системы Проблема с файлами отчетов об ошибках Windows?
  3. Как удалить файлы отчетов об ошибках Windows в очереди
  4. Метод 1. Запустите очистку диска с правами администратора
  5. Метод 2: Удаление файлов вручную
  6. Метод 3. Устранение ошибки журнала Windows 7 и 8
  7. Метод 4: Выполните установку с восстановлением

Что такое Windows с системной очередью Файлы отчетов об ошибках?

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

Что вызывает очередь системы Проблема с файлами отчетов об ошибках Windows?

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

  • Disk Cleanup не имеет прав администратора – это известно происходит, когда пользователь пытается запустить очистку диска без предоставления доступа администратора к утилите.
  • Утилита очистки диска дает сбой – в этом конкретном случае у вас есть возможность перехода к расположению файлов и их удаления вручную.
  • Ошибка сжатия файлов журнала Windows 7 и 8 . В Windows 7 есть давняя ошибка в Журнал надежного установщика, из-за которого ваш жесткий диск может заполниться без видимой причины.

Как удалить файлы отчетов об ошибках Windows в очереди

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

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

Метод 1. Запустите очистку диска с правами администратора

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

Как оказалось, очистка диска не сможет удалить пару системных файлов. если пользователь не предоставит ему доступ администратора. Вот краткое руководство, как это сделать:

  1. Нажмите клавишу Windows + R , чтобы открыть Выполнить диалоговое окно. Затем введите « cleanmgr » и нажмите Ctrl + Shift + Enter , чтобы открыть Очистку диска с правами администратора.
  2. В ответ на запрос UAC (контроль учетных записей пользователей) выберите Да . для принятия.
  3. Теперь выберите системные файлы отчетов об ошибках Windows в очереди и запланируйте их очистку. Вы сможете удалить их без проблем.

Если вы по-прежнему сталкиваетесь с той же проблемой, перейдите к следующему способу ниже.

Метод 2: Удаление файлов вручную

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

Вот краткое руководство как это сделать:

  1. Нажмите клавишу Windows + R, чтобы открыть диалоговое окно «Выполнить». Затем вставьте «% ALLUSERSPROFILE% Microsoft Windows WER ReportQueue » и нажмите Enter , чтобы открыть очередь отчетов .

    Примечание. Если эта команда не распознается, попробуйте следующее один вместо этого:

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

Если этот метод не сработал, продолжите следующий метод ниже.

Метод 3. Устранение ошибки журнала Windows 7 и 8

Если вы столкнулись с этой проблемой на Windows 7 и Windows 8, вы должны знать, что Microsoft имеет эту ошибку в течение нескольких лет, пока не выпустила исправление.

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

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

  1. Нажмите клавишу Windows + R , чтобы открыть Выполнить диалоговое окно. Затем введите « services.msc » и нажмите Enter , чтобы открыть экран «Службы». Если будет предложено UAC (Контроль учетных записей) , выберите Да.
  2. На экране Services прокрутите список служб вниз, чтобы найти Служба Установщик модулей Windows . Сделав это, дважды щелкните по нему, чтобы открыть меню Свойства .
  3. Как только вы войдете в меню свойств, перейдите к Вкладку Общие и нажмите Остановить , чтобы отключить службу Установщик модулей Windows (в разделе Состояние службы ).
  4. Откройте проводник и перейдите в C: Windows Logs CBS
    Примечание.     Если Windows установлена ​​на другом диске, измените местоположение соответствующим образом.
  5. В папке CBS переместите или переименуйте все файлы. Вы можете переименовать его как угодно, если сохраните расширение «.log».
  6. При появлении запроса UAC (контроль учетных записей) , выберите Да
  7. Перейдите к C: Windows Temp и удалите все файлы « .cab », которые в данный момент находятся в папке Temp .
  8. Перезагрузите компьютер и вернитесь к утилите очистки диска при следующем запуске. Вы больше не должны видеть большую запись Системная очередь отчетов об ошибках Windows .

Если этот конкретный метод не позволил вам решить проблему, перейдите к последнему методу ниже.

Метод 4: Выполните установку с восстановлением

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

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

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

Источник
  • Remove From My Forums

  • Question

  • On my windows 2008 servers CBS.log and alot CBS.persist.log consume alot of disk space. some forum / article mention CBS.persist.log are safe to delete but some article not recommence to remove it. Can the CBS.persist.log be deleted? any risk?

Answers

  • Hi,

    The SFC.exe program writes the details of each verification operation and of each repair operation to the CBS.log file. The CBS.persist.log
    is generated when the CBS gets to be around 50 meg in size. CBS.log is copied to cbs.persist.log and a new cbs.log file is started.

    It would be useful only for troubleshooting issues. If you are sure your system is running fine, you can delete this file. SFC.exe will
    create a new one, next time it is run.

    Hope this helps.

    Regards,

    Bruce

    • Marked as answer by

      Monday, December 5, 2011 2:22 AM

Источник
  • Remove From My Forums

  • Question

  • On my windows 2008 servers CBS.log and alot CBS.persist.log consume alot of disk space. some forum / article mention CBS.persist.log are safe to delete but some article not recommence to remove it. Can the CBS.persist.log be deleted? any risk?

Answers

  • Hi,

    The SFC.exe program writes the details of each verification operation and of each repair operation to the CBS.log file. The CBS.persist.log
    is generated when the CBS gets to be around 50 meg in size. CBS.log is copied to cbs.persist.log and a new cbs.log file is started.

    It would be useful only for troubleshooting issues. If you are sure your system is running fine, you can delete this file. SFC.exe will
    create a new one, next time it is run.

    Hope this helps.

    Regards,

    Bruce

    • Marked as answer by

      Monday, December 5, 2011 2:22 AM

Источник

Всем привет.

Начну с небольшого определения:
Что такое cbs.log?

Файл-лог журнала обслуживания windows, который содержит подробные сведения об ошибках автономного обслуживания, подробные сведения об ошибках интерактивного обслуживания, а так же как вспомогательный элемент для dism.exe

Не вдаваясь в тонкости осмысливания написанного ( определение взято отсюда ) сообщу следующее:

Многим из нас знакома программа sfc.exe, с помощь которой можно проверить состояние целостности защищенных системных файлов.
(Обсуждение в этой теме:

Обзор утилиты sfc.exe

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

Хорошо, если система рапортует о том, что защита ресурсов wiindows не обнаружила поврежденных файлов или что все поврежденные файлы восстановлены.
А что делать, если мы видим что то вроде такого сообщения?

Программа защиты ресурсов Windows обнаружила поврежденные файлы, но не может восстановить некоторые из них

Один из шагов к решению проблемы — это произвести анализ лога, который создается при сканировании. Лог-файл находится по пути %windir%logscbscbs.log и открыть его можно любым текстовым редактором, включая стандартный notepad.
Неподготовленный пользователь, открыв и посмотрев лог, скорее всего испытает острое желание закрыть файл и больше не открывать. Поэтому, для комфорта восприятия, пользователи придумали приводить лог в более читабельный вид, распарсив его и отфильтровав «лишние» записи оставить только те, что нужны.
Сделать это можно разными методами, кстати — в сети распространен метод с парсингом файла cbs.log введя в командной строке простую команду:

findstr/c: «[SR]» %windir%logscbscbs.log > "указать адрес, куда вы хотите сохранить лог"sfcdetails.txt

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

Как быть?
Для более комфортного первоначального анализа мы с коллегами создали такой скрипт:

Проверка целостности системных файлов утилитой sfc

Запустив скрипт вы сможете произвести проверку целостности системных файлов, произвести очистку и восстановление хранилища данных windows, в котором хранятся резервные копии защищенных системных файлов windows.
Из этих копий и производится восстановление поврежденных файлов.
Скрипт выводит аналогичный, но чуть более информативный лог + копирует в каталог запуска скрипта сам файл cbs.log.
А так же очищает старые записи, что немного экономит место на диске и спасает от зависаний компьютера ( при определенных условиях) при попытке открыть cbs.log. Да и читать будет удобнее и меньше.
Это связано с тем, что порой размер файла cbs.log может раздуваться и я видел монстров по 40 с лишним мегабайт… в общем, скрипт его «облегчает» до оптимального объема.
Идем дальше.
Пробуем читать cbs.log.

Что нужно знать?

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

И, если по каким то причинам не удалось получить доступ к файлам или в хранилище они тоже оказались повреждены — в таком случае периодически мы можем наблюдать сообщение о невозможности восстановления файлов.
К которому бонусом может присоединиться какая нибудь трабла в работе системы.
=========================================================

Напомню, что лог cbs.log находится по такому пути:

* предварительно необходимо

включить отображение скрытых и системных файлов.

=========================================================

Вернемся, непосредственно, к файлу cbs.log. Вы его уже открыли в текстовом редакторе?
Открывайте.
Лично мне более удобным для работы с файлами такого типа является редактор notepad++
Так как редакторов много и каждый волен выбирать тот, что ему по душе — то далее я буду описывать свои действия в редакторе в контексте интерфейса notepad++ , а вы (если пользуетесь другим) , можете ориентироваться по аналогии в своем.

Думаю вы уже до этого находили информацию о том, что нужные нам действия помечаются тегом [SR] в каждой строке — именно по этому признаку и принято парсить cbs.log. А если вы не знали — значит узнали теперь)
Теперь у нас с вами два варианта: либо переходить сразу к проблемным файлам через поиск (это если у вас уже есть отфильтрованый одним из упомянутых методов лог) либо вывести все строки с тегом [SR].
Я лично всегда так делаю — легче потом будет навигация.
В notepad++ есть возможность вывести в дополнительной области все найденные по маске ( тегу [SR] ) строки.

Делается это просто: открываем поиск (кнопка в виде бинокля), вводим в строку поиска [SR], далее нажимаем кнопку «Найти все в текущем документе» и получаем в нижней области программы все строки найденные по нужному фильтру, а в вверхней области основной текст файла cbs.log, как видно на скриншоте:

1517323608718

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

Далее в нижней области, где отфильтрованы строки с тегом [SR] пропускаем все что выглядит примерно так:

2018-01-22 19:54:56, Info                  CSI    00000015 [SR] Verifying 100 (0x0000000000000064) components
2018-01-22 19:54:56, Info                  CSI    00000016 [SR] Beginning Verify and Repair transaction
2018-01-22 19:54:59, Info                  CSI    00000018 [SR] Verify complete

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

Как только находим нечто отличающееся — стоп.
Например:
2017-10-29 21:28:40, Info CSI 000001e1 [SR] Cannot repair member file [l:24{12}]"gpscript.exe" of Microsoft-Windows-GroupPolicy-Script, Version = 6.1.7601.23452, pA = PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch

Все, сейчас мы нашли то, что надо.
Если вбить в переводчик то, что написано раздельным текстом, то можно вполне понять что не так.
На примере данной строки давайте и разберемся.

Cannot repair member file  - не удается восстановить файл-член...
PublicKey neutral in the store, hash mismatch - Открытый ключ нейтральный  в магазине, несоответствие хэша

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

2017-10-29 21:28:40, Info                  CSI    000001e0 Hashes for file member SystemRootWinSxSx86_microsoft-windows-grouppolicy-script_31bf3856ad364e35_6.1.7601.23452_none_677acd98e72e71ccgpscript.exe do not match actual file [l:24{12}]"gpscript.exe" :
  Found: {l:32 b:yHkCWhwG8j0IOFAIlAuv4/o6FtEO2tqdJOWtoUpBlck=} Expected: {l:32 b:GQ5AzLEfZ9lH3YTPo9vNHTiesdUCuZnB7IW2XQQmn1c=}
2017-10-29 21:28:40, Info                  CSI    000001e1 [SR] Cannot repair member file [l:24{12}]"gpscript.exe" of Microsoft-Windows-GroupPolicy-Script, Version = 6.1.7601.23452, pA = PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch
2017-10-29 21:28:40, Info                  CSI    000001e2 [SR] This component was referenced by [l:154{77}]"Package_40_for_KB3159398~31bf3856ad364e35~x86~~6.1.1.1.3159398-40_neutral_LDR"

Тут мы отчетливо видим, что файл в хранилище должен быть по адресу:
Hashes for file member SystemRootWinSxSx86_microsoft-windows-grouppolicy-script_31bf3856ad364e35_6.1.7601.23452_none_677acd98e72e71ccgpscript.exe
Версия его: Version = 6.1.7601.23452 и на него ссылается компонент патча KB3159398.
Открываем упомянутый патч на сайте Microsoft:
Download Обновление для системы безопасности Windows 7 (KB3159398) from Official Microsoft Download Center
Находим там ссылку «Связанные ресурсы», переходим.
https://support.microsoft.com/ru-ru…-the-security-update-for-group-policy-june-14
Открываем сведения о файлах и находим тот, что нам нужен:

1517332469390

​

Все, значит это то, что нам нужно.
Просто переустанавливаем это обновление и нужные файлы перезаписываются. А значит — все станет ОК.

Это был пример на живом логе реальной системы.

Почему необходимо найти именно такой же файл и такой же версии?
Потому что когда данный файл внедрялся в систему, то создается ряд условий, на основании которых система защиты будет считать «правильным» только такой файл, который будет соответствовать этим самым условиям.
Другими словами, если какое то из обновлений системы, к примеру, обновляло версию файла и эталоны, то файл из ранее сделанной резервной копии, но другой версии будет считаться неактуальным.
Именно поэтому часто встречающуюся рекомендацию:
Вставьте диск (флэшку) с дистрибутивом вашей версии операционной системы и введите sfc / scannow …
Можно смело пропускать мимо ушей, глаз или как там еще информация дошла до вас.

Почему?

Тут имеется очень важный нюанс — дистрибутив должен быть именно таким же.
То есть с точно таким же набором обновлений, патчей и заплаток.
А найти такой дистрибутив довольно сложно, если вообще будет возможным.

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

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

Отсюда можно сделать вывод, что при первоначальной проверке заморачиваться на счет наличия дистрибутива не стоит.
Исключение Windows XP — там система потребует наличия папки I386, которая имеется как раз на дистрибутиве (если у вас нет где то отдельно).
В нашем скрипте проверка ее наличия осуществляется автоматически и пользователю не придется выполнять танцы с бубном для того, что бы указать системе где она, если не удастся обнаружить.
Достаточно смонтировать образ диска и все.

Как еще можно восстановить поврежденные файлы?

Можно попытаться выполнить автоматическое восстановление хранилища компонентов через пункт «Расширенная проверка и восстановление файлов» скрипта, или запустив командную строкуот имени Администратора и ввести команду:
(Для Windows 8 — 10)
dism /Online /cleanup-image /restorehealth

Для Windows 7 команда будет выглядеть немного иначе, а так же потребуется наличие установленного Download Обновление для Windows 7 (KB2966583) from Official Microsoft Download Center

DISM /Online /Cleanup-Image /ScanHealth

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

=================================

Если вам понадобилось восстановление файлов хранилища данных вручную — то вам понадобится

стать владельцем объекта и получить права на изменение.

=================================

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

Для того, что бы облегчить себе задачу и сэкономить время+силы, я использую для первоначального анализа файл sfcdoc.log, создаваемый скриптом.
Можно использовать и sfcdetalis.txt — но он менее информативен.

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

------ SFCDoc parsing (start process) ------

Там выводится результат работы программы sfc.exe, который записывается в cbs.log и имеет строки с тегом [sr]
Программа sfc.exe проверяет файлы блоками по 100 штук, отсюда и появляются записи типа:

000028a5 [SR] Verify complete
000028a6 [SR] Verifying 100 components
000028a7 [SR] Beginning Verify and Repair transaction

Итак, в логе sfcdoc.log (или sfcdetalis.txt) мы находим примерно такие строки:

00004fa9 [SR] Cannot repair member file [l:12]'userinit.exe' of Microsoft-Windows-UserInit, version 10.0.15042.0, arch Host= amd64 Guest= x86, nonSxS, pkt {l:8 b:31bf3856ad364e35} in the store, hash mismatch
00004fac [SR] Cannot repair member file [l:12]'userinit.exe' of Microsoft-Windows-UserInit, version 10.0.15042.0, arch Host= amd64 Guest= x86, nonSxS, pkt {l:8 b:31bf3856ad364e35} in the store, hash mismatch
00004fad [SR] This component was referenced by [l:181]'Microsoft-Windows-Client-Features-WOW64-Package-AutoMerged-onecore~31bf3856ad364e35~amd64~~10.0.15042.0.Microsoft-Windows-Client-Features-WOW64-Package-AutoMerged-onecore-Deployment
00004fb0 [SR] Could not reproject corrupted file ??C:WindowsSysWOW64userinit.exe; source file in store is also corrupted

Это файлы, которые не удалось восстановить, либо те, что были восстановлены.

Если буквально, то Could not reproject corrupted file ??C:WindowsSysWOW64userinit.exe значит что указанный файл не удалось восстановить из хранилища.
А source file in store is also corrupted — это говорит нам о том, что в хранилище файл тоже поврежден.

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

Теперь имеет смысл обратиться к файлу cbs.log.
Скопируйте его в удобное место из каталога

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

Notepad++

Открываем cbs.log и ищем ближайшую с конца строку с искомым нам файлом: в данном случае это userinit.exe

2017-10-26 23:38:05, Info                  CSI    000041c2 Hashes for file member SystemRootWinSxSwow64_microsoft-windows-userinit_31bf3856ad364e35_10.0.15042.0_none_f7a5dd2f3ed02235userinit.exe do not match actual file [l:12]'userinit.exe' :
  Found: {l:32 mhHTAD/21TkyflJQwItWEJZr9UaGJebx3CamF6tUPf4=} Expected: {l:32 +bkkt7edQArLakaOJRdpxV8MvpFumMUD88WNy60YfA0=}
2017-10-26 23:38:05, Info                  CSI    000041c3 [SR] Cannot repair member file [l:12]'userinit.exe' of Microsoft-Windows-UserInit, version 10.0.15042.0, arch Host= amd64 Guest= x86, nonSxS, pkt {l:8 b:31bf3856ad364e35} in the store, hash mismatch
2017-10-26 23:38:05, Info                  CSI    000041c4 [SR] This component was referenced by [l:181]'Microsoft-Windows-Client-Features-WOW64-Package-AutoMerged-onecore~31bf3856ad364e35~amd64~~10.0.15042.0.Microsoft-Windows-Client-Features-WOW64-Package-AutoMerged-onecore-Deployment'
2017-10-26 23:38:05, Info                  CSI    000041c5 Hashes for file member ??C:WindowsSysWOW64userinit.exe do not match actual file [l:12]'userinit.exe' :
  Found: {l:32 K1Y9CBrNZsBLg7IsV/u9IEgYQ9xrk8frQkTDRknlyMA=} Expected: {l:32 +bkkt7edQArLakaOJRdpxV8MvpFumMUD88WNy60YfA0=}
2017-10-26 23:38:05, Info                  CSI    000041c6 Hashes for file member SystemRootWinSxSwow64_microsoft-windows-userinit_31bf3856ad364e35_10.0.15042.0_none_f7a5dd2f3ed02235userinit.exe do not match actual file [l:12]'userinit.exe' :
  Found: {l:32 mhHTAD/21TkyflJQwItWEJZr9UaGJebx3CamF6tUPf4=} Expected: {l:32 +bkkt7edQArLakaOJRdpxV8MvpFumMUD88WNy60YfA0=}
2017-10-26 23:38:05, Info                  CSI    000041c7 [SR] Could not reproject corrupted file ??C:WindowsSysWOW64userinit.exe; source file in store is also corrupted

Что мы видим?
Hashes for file member ….. do not match actual file
Эта запись гласит о том, что хэш сумма файла не совпадает с оригинальным.
Это и есть причина.
Где надо заменить файл?

SystemRootWinSxSwow64_microsoft-windows-userinit_31bf3856ad364e35_10.0.15042.0_none_f7a5dd2f3ed02235userinit.exe

Запомните, что SystemRootWinSxS — это адрес расположения хранилища данных.
Где SystemRoot эквивалентен переменной %SystemRoot% — путь до каталога windows на системном диске.

wow64 — это говорит нам о том, что речь идет о 64 разрядной системе и версии файла.

Строка

Cannot repair member file [l:12]'userinit.exe' of Microsoft-Windows-UserInit, version 10.0.15042.0

отображает так же служебную информацию, тут нам важно отметить что исходя из этой записи мы видим, что речь идет о версии файла 10.0.15042.0 (version 10.0.15042.0).
Это значит, что мы должный найти точно такую же версию файла и произвести замену в указанном каталоге.
Равно как и в каталоге C:WindowsSysWOW64userinit.exe
Тут есть особенность: так как произвести замену C:WindowsSysWOW64userinit.exe в загруженной системе вряд ли удастся, то вам либо придется сделать это из среды восстановления (в таком случае путь будет Х:Windowsuserinit.exe, где Х — это системный диск), либо из под Live CD/USB, либо — самый оптимальный вариант — просто производим замену в харнилище, а затем производим стандартную проверку sfc /scannow и система все сделает за вас сама.
То есть восстановит поврежденные файлы из хранилища.

* узнать версию файла можно кликнув по нему правой кнопкой мыши — свойства -Подробно.

Upload 2017 11 11 16 12 59

==================================================

Далее разберем следующие строки лога cbs.log

Found: {l:32 b:yHkCWhwG8j0IOFAIlAuv4/o6FtEO2tqdJOWtoUpBlck=} Expected: {l:32 b:GQ5AzLEfZ9lH3YTPo9vNHTiesdUCuZnB7IW2XQQmn1c=}
2017-10-29 21:28:40, Info                  CSI    000001dd [SR] Cannot repair member file [l:24{12}]"gpscript.exe" of Microsoft-Windows-GroupPolicy-Script, Version = 6.1.7601.23452, pA = PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch
2017-10-29 21:28:40, Info                  CSI    000001de [SR] Cannot repair member file [l:72{36}]"Microsoft.Build.Engine.resources.dll" of Microsoft.Build.Engine.resources, Version = 3.5.7600.16385, pA = PROCESSOR_ARCHITECTURE_MSIL (8), Culture = [l:10{5}]"ru-ru", VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:b03f5f7f11d50a3a}, Type neutral, TypeName neutral, PublicKey neutral in the store, file is missing
2017-10-29 21:28:40, Info                  CSI    000001df [SR] This component was referenced by [l:168{84}]"Microsoft-Windows-NetFx3-OC-Package~31bf3856ad364e35~x86~ru-RU~6.1.7601.17514.NetFx3"
2017-10-29 21:28:40, Info                  CSI    000001e0 Hashes for file member SystemRootWinSxSx86_microsoft-windows-grouppolicy-script_31bf3856ad364e35_6.1.7601.23452_none_677acd98e72e71ccgpscript.exe do not match actual file [l:24{12}]"gpscript.exe" :
  Found: {l:32 b:yHkCWhwG8j0IOFAIlAuv4/o6FtEO2tqdJOWtoUpBlck=} Expected: {l:32 b:GQ5AzLEfZ9lH3YTPo9vNHTiesdUCuZnB7IW2XQQmn1c=}
2017-10-29 21:28:40, Info                  CSI    000001e1 [SR] Cannot repair member file [l:24{12}]"gpscript.exe" of Microsoft-Windows-GroupPolicy-Script, Version = 6.1.7601.23452, pA = PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch
2017-10-29 21:28:40, Info                  CSI    000001e2 [SR] This component was referenced by [l:154{77}]"Package_40_for_KB3159398~31bf3856ad364e35~x86~~6.1.1.1.3159398-40_neutral_LDR"

Cannot repair member file … hash mismatch

Здесь так же говорится, что файл такой то не удалось восстановить и имеется несоответствие суммы хэш.

А вот запись in the store, file is missing говорит о том, что файл не просто поврежден, а полностью отсутствует в хранилище компонентов.

А вот эта строка

2017-10-29 21:28:40, Info                  CSI    000001e2 [SR] This component was referenced by [l:154{77}]"Package_40_for_KB3159398~31bf3856ad364e35~x86~~6.1.1.1.3159398-40_neutral_LDR"

нам говорит о том, что этот компонент связан с обновлением KB3159398.
Если найти в базе Microsoft соответствующую ссылку, то там в перечне изменяемых файлов мы как раз увидим, что обновление выполняет установку файла необходимой версии.
Другими словами решением будет — переустановка обновления KB3159398.

Вот еще один интересный вариант, который вам может попасться в логе:

9:15, Error                 CSI    00000187 (F) Failed on regenerating file [l:22{11}]"browaub.ttf"[gle=0x80004005]

Здесь говорится о том, что попытка восстановления файла была завершена с ошибкой 0x80004005
Не буду вас гонять по поисковикам и скажу сразу что в данном случае процесс блокировал брандмауэр Windows, как бы бредово это не звучало)

P.S.
Далее будут в таком же формате излагаться другие варианты, если есть вопросы и замечания пишите.

Источник

Понравилась статья? Поделить с друзьями:
  • Windows 7 logon julien manici com
  • Windows 7 logon background changer скачать бесплатно на русском
  • Windows 7 logon background changer не работает
  • Windows 7 logon background changer как пользоваться
  • Windows 7 logon background changer torrent