Есть еще файлы, не защищённые SFC. Они тоже подвержены повреждению. Можешь выдернуть список через HiJackThis. Их можно тоже проверить, например, через валидность ЭЦП.Итак, если sfc не справляется, то :
А решать эту проблему не пробовал?Ignoring duplicate ownership for directory
Что это за каталоги и на что влияют?Находим пустые каталоги и выводим их список в лог .
Можно ещё выполнить команду отката обновления, если знать, какой файл в каком из них.Есть мысль выдергивать из wim образа поврежденные \ отсутствующие файлы в C:\windows\WinSxS
Это если в образе есть соответствующая версия. А пропатченый обновлением файл ты откуда будешь дёргать?Есть мысль выдергивать из wim образа поврежденные \ отсутствующие файлы в C:\windows\WinSxS
Наверное обсуждение - важная часть, которой я ждал от тех, кто проявит желание.А детальное ТЗ будет или это всё на уровне обсуждений?
на счёт версионности ?
findstr/c:"[SR]" %windir%\Logs\CBS\CBS.log > %userprofile%\Desktop\sfcdetails.txt
sfc /SCANFILE=*.* /OFFBOOTDIR=d:\ /OFFWINDIR=d:\windows
Есть еще файлы, не защищённые SFC. Они тоже подвержены повреждению. Можешь выдернуть список через HiJackThis. Их можно тоже проверить, например, через валидность ЭЦП.
А решать эту проблему не пробовал?
Что это за каталоги и на что влияют?
Можно ещё выполнить команду отката обновления, если знать, какой файл в каком из них.
На этот вопрос уже ответил выше, разве что добавлю момент - хочется видеть о таких файлах информацию о версии,хэш,эцп... для тех, которые не удастся восстановить по описанной системе.Это если в образе есть соответствующая версия. А пропатченый обновлением файл ты откуда будешь дёргать?
Каталоги безопасности тоже обновляются вместе с накатыванием обновления. Остаются ли там старые хеши, я не знаю. Думаю, что нет. Но, нужно проверять.Те файлы, которые окажутся более старой модификации останутся работоспособными, так как в каталоге безопасности системы они должны все равно числиться.
можно либо накатить обновление заново, либо брать изначально актуальную версию файла.
утилита SFC? Тогда это не согласуется с первым утверждением.Всю работу по сопоставлению легитимности файлов должна брать на себя утилита.
Пока не понятно, как это будет выглядеть на стороне пользователя. Он скачивает оригинальный образ? В котором все равно нет новых версий файлов. Так то SFC никакой замены не произвёдет. А для Windows 10 будет ещё большая проблема найти подходящий образ в связи с выходом различных билдов вместо старой модели простых хотфиксов.Тут я как то плавно перешел к тому, что мы получаем новые возможности при работе с Wim - необходимость проверки в режиме среды восстановления благодаря этому сведется почти к нулю, за исключением случаев, когда необходимо заменить файлы используемой системой.
А что за ссылки? Приведи одну. Я хотя бы посмотрю о чём речь.Я пока еще определяюсь с принципом ссылок на них в реестре, поэтому пока только проверка на пустые при записи file missing
Что именно не захватывается? Я честно, давно не смотрел никакие логи, так что трудно войти в курс.Причем общепринятый парсинг по строке [sr]
оказался тоже малоинформативен на сегодня и почти всегда нужно просить все равно полный лог.
Для этого нужно парсить базу, откуда SFC берёт инфу о каждом файле. Я пока даже не знаю, где эта база находится. Функции SFC недокументированны. Единственное, что я раскопал - список подзащитных файлов без какой-либо доп. инфы. Ну + из каталогов безопасности можно извлечь PE256 hash всех файлов, если тебе нужно для тестов.На этот вопрос уже ответил выше, разве что добавлю момент - хочется видеть о таких файлах информацию о версии,хэш,эцп... для тех, которые не удастся восстановить по описанной системе.
Для доработки следующей версии скрипта.
1) Это больше актуально для Windows 8 и выше, где используются усиленные меры проверки подлинности файла, прежде чем система разрешит запуск такого файла на исполнение (механизм Signing Levels, детально описанный Алексом Ионеску). Другими словами, если файл не подписан, или не удаётся выполнить проверку подписи, то он не запустится.
По DISM ты вроде делал тестовый скрипт с установкой хотфикса для добавления в 7 функционала, только он у тебя почему то не сработал.
Откуда брал инфу об этом способе?
Ссылки на реестр - под рукой такого лога нет сейчас.А что за ссылки? Приведи одну. Я хотя бы посмотрю о чём речь.
Давай подтягивай логи. Можно для начала хотя бы подредактировать скрипт Фильтрация лога SFC /scannowА,например, тот же file missing говорит об отсутствии исходного файла в одном из каталогов хранилища.
И если смотреть только [sr] строки, то мы не увидим в каком именно каталоге.
Это я уже сам смотрел, проверял.
Можно по событиям через мониторинг файловой системы, запущенный на время проверки. Вот асинхронная следилка.А хр будем парсить по событиям.
@echo off
del cbs3.log
<cbs.log findstr /vi /c:"owned" /C:"duplicate" /C:"primitive" /C:"Verify complete" /C:"Verifying 100" /c:"Beginning Verify" /C:"SysprepPI Commit" /c:"FilePI Commit" /C:"FileMapsCreated" /C:"FilePI Queue" /C:"Original owner" /C:"New owner" > cbs2.log
::удаление пустых строк
for /f "delims=" %%a in (cbs2.log) do echo.%%a>>cbs3.log
pause
Что я сделал.Каталоги безопасности тоже обновляются вместе с накатыванием обновления. Остаются ли там старые хеши, я не знаю. Думаю, что нет. Но, нужно проверять.
Ты сможешь это сделать без поиска в интернете?мы по логу должны просто сказать откуда и что с серверов ms надо скачать
Пока что нет.Ты сможешь это сделать без поиска в интернете
Типа парсим эту страницу, распаковываем все архивы, парсим манифест, вытягиваем имя файла, создаём базу привязок KB <-> имена файлов / версия. (?)Точнее, пока не придумать систему какую нибудь.
Особенно, если отдать на растерзание КириллуНа самом деле читать его не так и сложно, даже если вовсе не парсить.
Да, это будет актуальней.Параллельно этому сделать мануал как можно, по возможности, самому разбирать лог.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?