Microsoft windows client cbs что это
Восстановление компонента прямой заменой файлов
В данной статье описан метод ручного восстановления хранилища компонентов Windows. Подобные описанному в данном посте методу восстановления работоспособности компонентной модели рождаются вовсе не от хорошей жизни, появляются они под воздействием многочисленных проблем с компонентной моделью операционной системы. Во многих случаях официальные подходы к восстановлению хранилища компонентов не помогают, помимо этого отсутствует какая бы то ни было внятная официальная документация, из чего складывается недопонимание структуры и принципов работы компонентной модели. При подобном отношении со стороны разработчиков абсолютно любые средства вернуть компонентную модель в работоспособное состояние приемлемы!! Как показывает практика, при всех стараниях разработчиков из Microsoft предоставить возможность конечному пользователю системы устранять возникающие проблемы в автоматическом режиме (при помощи специальных утилит), никогда полностью не будут исключены ситуации, в которых эти самые автоматизированные средства будут давать сбои. Причина тут кроется в симбиозе старых механизмов операционной системы и необходимостью постоянного внедрения новых (не оттестированных) технологий, должным образом не заботясь о приведении в надлежащее состояние всех связанных (участвующих) компонентов, что, в свою очередь, порождает огромное количество проблем.
В данной публикации речь пойдет о восстановлении компонента прямой заменой файлов. Фактически методом предусматривается прямая ручная замена поврежденных [кривых, неправильно функционирующих] файлов, являющихся причиной возникновения ошибок, а так же частей реестра. По этой методике, исправные файлы и соответствующие ключи реестра копируются с работоспособной станции-донора. Слабое место метода в том, что для реализации требуется наличие находящейся на том же уровне обновлений нормально функционирующей операционной системы той же версии/ревизии.
В процессе повествования постараемся описать общую методику, тем не менее, в статье будут присутствовать частные случаи из практики.
Определение виновника проблемы
В этом разделе мы опишем принцип поиска битых файлов в составе иерархии каталогов компонентной модели, являющихся причиной возникновения сбоев. Так же попытаемся классифицировать все возможные источники информации о сбойных модулях.
Ошибки в лог-файлах
Что такое CBS.log? Как прочитать файл CBS.log в Windows 10
Ошибки Windows Update или SFC в Windows 10 сохраняются в файле CBS.log. В этой статье мы рассмотрим, что такое CBS.log, его расположение и как просмотреть файл CBS.log в Windows 10.
Что такое CBS.log
CBS или Component-Based Servicing — это файл, содержащий логи об установленных и удаленных компонентах Windows Update. Таким образом, информация о вашем Windows Update хранится в этих файлах журнала, даже System File Checker (SFC) пишет в CBS.log.
Расположение файла CBS.log
Файл CBS.log всегда будет присутствовать на вашем компьютере под управлением Windows. Если вам интересно и вы хотите проверить этот файл, запустите Проводник (Win + E) и перейдите в следующее место.
Там вы увидите имя файла CBS.log. Это тот самый файл, который содержит информацию о Windows Update.
Как прочитать файл CBS.log
Вы можете просто открыть его с помощью Блокнота.
Однако если вы хотите просто прочитать файл SFC, это не лучший вариант.
Для этого запустите Командную строку с правами администратора, введите следующую команду и нажмите Enter.
Это создаст файл sfclogs.txt на рабочем столе. Дважды щелкните по нему, чтобы открыть файл с помощью Блокнота, и прочитайте его. Вы увидите, что перед каждой транзакцией написано «SR». Это означает, что все показанные здесь программы относятся к SFC.exe.
Могу ли я удалить файл CBS.log?
Файл CBS.log необходим для вашего компьютера, поскольку каждый раз, когда вы устанавливаете новое обновление Windows, оно записывается в файл CBS.log. Однако если вам кажется, что он съедает огромный кусок вашего жесткого диска, то можете удалить его, так как это не окажет негативного влияния на ваш компьютер.
Перед этим обязательно отключите службу Windows Update.
Теперь вы можете удалить файл CBS.log, и вы не получите никакого сообщения об ошибке.
Поврежденные файлы регистрируются в журнале CBS.log
В некоторых Windows может возникнуть ошибка следующего содержания
Защита ресурсов Windows обнаружила поврежденные файлы, но не смогла исправить некоторые из них. Подробности содержатся в журнале CBS.Log windir\Logs\CBS\CBS.log.
Чтобы исправить эту проблему, вам может потребоваться запустить DISM.
Спасибо, что читаете! Подписывайтесь на мои каналы в Telegram, Яндекс.Мессенджере и Яндекс.Дзен. Только там последние обновления блога и новости мира информационных технологий.
Респект за пост! Спасибо за работу!
Хотите больше постов? Узнавать новости технологий? Читать обзоры на гаджеты? Для всего этого, а также для продвижения сайта, покупки нового дизайна и оплаты хостинга, мне необходима помощь от вас, преданные и благодарные читатели. Подробнее о донатах читайте на специальной странице.
Заранее спасибо! Все собранные средства будут пущены на развитие сайта. Поддержка проекта является подарком владельцу сайта.
Последние
Реклама
telegram
Рубрики
СЧЕТЧИКИ
РЕКЛАМА И ДОНАТЫ
Социальные сети
©2016-2021 Блог Евгения Левашова. Самое интересное и полезное из мира ИТ. Windows 10, Linux, Android и iOS. Обзоры программ и веб-сервисов. Статьи о мотивации и продуктивности.
Использование материалов разрешается с активной ссылкой на levashove.ru.
Данный блог является личным дневником, содержащим частные мнения автора. В соответствии со статьей 29 Конституции РФ, каждый человек может иметь собственную точку зрения относительно его текстового, графического, аудио и видео наполнения, равно как и высказывать ее в любом формате. Блог не имеет лицензии Министерства культуры и массовых коммуникаций РФ и не является СМИ, а, следовательно, автор не гарантирует предоставления достоверной, не предвзятой и осмысленной информации. Сведения, содержащиеся в этом блоге не имеют никакого юридического смысла и не могут быть использованы в процессе судебного разбирательства. Автор блога не несёт ответственности за содержание комментариев к его записям.
Как исправить обслуживание на основе компонентов (cbs.log) с использованием чрезмерного дискового пространства
Компонентное обслуживание (cbs.log) может начать использовать все пространство на диске, если системные файлы повреждены или если обновление Windows постоянно не устанавливается. Проблема возникает, когда пользователь видит, что его системный диск заполнен (или большая часть диска занята) журналами CBS. Но после удаления файлов журналы снова стремительно увеличиваются в размерах.
Прежде чем переходить к уменьшению размера журнала CBS, обязательно сбросьте ассоциацию файлов на значения по умолчанию (Настройки> Приложения> Приложения по умолчанию> Сбросить до рекомендованных Microsoft значений по умолчанию).
Сброс до рекомендованных Microsoft значений по умолчанию
Решение 1. Удалите файлы журнала CBS
Файлы журнала CBS разделяются на разные файлы, когда размер файла достигает 50 МБ, а затем сжимаются для экономии места на диске. Но проблема возникает, когда размер файла журнала CBS (из-за сбоя) увеличивается до 2 ГБ (после чего Makecab не может его сжать), и размер файла начинает быстро расти. В этом контексте удаление файлов CBS может решить проблему.
Если вы не можете остановить установщик модулей Windows, попробуйте следующий метод:
Решение 2. Выполните сканирование SFC
Проблема CBS.log может возникнуть, если основные системные файлы повреждены. В этом контексте выполнение сканирования SFC может устранить повреждение файлов и, таким образом, решить проблему.
Решение 3. Выполните автономное обновление вручную
CBS.log мог занять большую часть дискового пространства, если обновление постоянно не устанавливается, а повторные попытки могут вызвать быстрый рост файла CBS. В этом случае ручная установка автономного обновления может устранить сбой и тем самым решить проблему.
Решение 4.Используйте планировщик задач для удаления файлов журнала CBS
Если приведенные выше решения не помогли вам, вы можете создать повторяющуюся задачу в планировщике задач для удаления файлов журнала CBS, что остановит потребление дискового пространства журналами CBS и, таким образом, решит проблему.
Решение 5. Отредактируйте системный реестр, чтобы остановить создание файлов журнала CBS.
Если ни одно из решений не помогло вам, то редактирование системного реестра для отключения журнала CBS может решить проблему (не забудьте включить этот параметр после того, как проблема будет решена).
Предупреждение: продвигайтесь вперед с особой осторожностью и на свой страх и риск, так как редактирование системного реестра — это умелая работа, и если ее не сделать должным образом, вы можете нанести непоправимый ущерб вашему компьютеру / данным.
TextInputHost.exe — что это за процесс? (Windows 10, Text Input Host)
Приветствую. Данная заметка опишет предназначение компонента textinputhost.exe, который может содержать операционная система OS Windows 10.
TextInputHost.exe — что это за процесс? (Text Input Host)
Коротко ответ: обеспечивает ввод с виртуальной сенсорной тач-клавиатуры (при использовании обычной клавиатуры — можно отключить).
Название процесса в версиях Виндовс начиная с билда 2004 — InputApp. Компонент может нагружать графический адаптер (GPU).
Папка запуска процесса:
Директорию запуска можно проверить вручную: откройте диспетчер задач (Win + R > taskmgr), найдите процесс, кликните правой кнопкой > выберите пункт Открыть расположение. Далее откроется папка, будет выделенный файл TextInputHost.exe. Вверху проверьте путь каталога. Если отсутствует название директории SystemApps — стоит просканировать компьютер на наличие угроз лучшими утилитами (Dr.Web CureIt!, AdwCleane, HitmanPro), возможно TextInputHost.exe — вирус.
TextInputHost.exe — как отключить?
Второй способ — откройте окно Конфигурация системы (Win + R > команда msconfig), активируйте вкладку Службы > снимите галочку:
Сохраните изменения кнопкой ОК, выполните перезагрузку операционки.
Перед вмешательством в операционную систему Windows 10 — желательно сперва создать точку восстановления.
«Неуловимый» список установленных обновлений Windows
Вы когда-нибудь задумывались, с помощью чего формируется список установленных обновлений Windows? А через какое API его достать? Ответы на эти и другие возникающие вопросы я постараюсь дать в своём небольшом исследовании.
Предыстория или с чего всё началось.
В нашей компании каждый год проходит конференция молодых специалистов, где каждый участник может решить проблему какого-либо отдела (список тем заранее предлагается).
Раньше на каждое «ТО» с помощью WSUS подтягивались все выпущенные обновления и распространялись на все машины. Также периодически выходили ТСБ (технические сервисные бюллетени), в которых указывалось, что требуется установить необходимые обновления в виде изолированных пакетов. В итоге у нас накапливаются обновления, которые в WSUS отследить нельзя, а можно было увидеть только через панель управления в разделе «Установленные обновления».
Бывают ситуации, когда АРМ или сервер «падает» и приходится его восстанавливать из образа, созданного некоторое время назад. При восстановлении из образа есть вероятность того, что мы можем потерять нужные нам обновления (которые пришли в виде изолированных пакетов), которые устанавливались до падения машины. Объяснил максимально подробно насколько мог, потому что уточнения будут уже коммерческой тайной.
Вот поэтому и возникла идея создать программу, которая бы могла извлечь этот список обновлений (желательно удаленно по локальной сети), записать в файл/базу, сравнить текущий перечень с неким шаблоном и выдать сообщение на SCADA систему через один из протоколов — SNMP, OPC.
Как вы могли догадаться из названия статьи, уже на выборе метода получения списка у меня возникла непростая задача. Я, как обычно, решил поискать нужное в поисковике, задал вопросы на профильных ресурсах (раз, два, на английском stackoverflow почему-то не понравился мой вопрос и его пришлось удалить), но все ответы не давали нужного результата. Поэтому пришлось разбираться самому, о чем и пойдет речь далее.
Консольные команды
Начнем с простого и воспользуемся тем, что предлагает нам Windows без использования сторонних средств. Это можно сделать с помощью следующих команд:
Вывод консольной команды можно перенаправить в файл и дальше начать его парсить, но это неправильно, плюс вызов программы (по правилам СБ не пройдет) и об удаленном получении списка речь не идёт. Поэтому предлагаю вам просто вызвать команды, сравнить количество обновлений в каждом списке, со списком через Панель управления и продолжить наше расследование дальше.
Формально все методы получения списка обновлений можно разделить на две группы: локальные и сетевые.
Все методы проверялись на чистых образах систем (Windows 7, 8, Server 2012 R2) с интегрированными обновлениями, после каждого обновления через Центр обновления с официальных серверов Microsoft проводилась дополнительная проверка. Остановимся на каждом из них подробнее.
Примечание: далее для своего удобства все результаты я буду вставлять в List. Это, возможно, не рационально, но тогда мне это казалось хорошей идеей.
Есть и вторая вариация этого метода: Update Session — получение информации с помощью подключения к сессии обновления Windows Update Agent (в данном случае работаем не напрямую с библиотекой).
Microsoft подсказывает об удаленном использовании API.
Главный минусы этих двух методов — не позволяют найти исправления KB, которые не распространяются через Центр обновления Windows. Можно увидеть только то, что прошло через сам агент обновления, то есть данный вариант нас не устраивает.
Система обслуживания образов развертывания и управления ими (Deployment Image Servicing and Management) — это средство командной строки, которое может использоваться для обслуживания образа Windows или для подготовки образа среды предустановки Windows (Windows PE). Является заменой диспетчера пакетов (Pkgmgr.exe), PEimg и Intlcfg.
Данная утилита используется для интеграции обновлений, сервис паков в образ системы. Обновления Windows представляют собой отдельные модули, которые могут быть представлены в нескольких вариантах:
Количество обновлений совпадало с количеством из списка Панели управления до первого апдейта через центр управления — после него количество обновлений стало меньше (было 214, стало 209), хотя по логике они должны были увеличиться. Примеры вывода До обновления, После обновления.
С чем это связано я могу только предполагать — возможно, какие-то обновления замещали предыдущие, следовательно, и количество стало меньше.
Чуть позже я наткнулся на утилиту от китайцев DISM++, которая основана не на DISM API или DISM Core API, но имеющиеся в ней библиотеки не имеют нужных мне открытых методов, поэтому я забросил эту идею и продолжил поиски дальше.
Windows Server Update Services (WSUS) — сервер обновлений операционных систем и продуктов Microsoft. Сервер обновлений синхронизируется с сайтом Microsoft, скачивая обновления, которые могут быть распространены внутри корпоративной локальной сети. Опять же специальный инструмент, предназначенный для работы с обновлениями.
Распространяется только на серверных редакциях ОС Windows, поэтому был развернут следующий стенд:
Чтобы не выделять раздел жесткого диска для новой системы я пользуюсь WinNTSetup и устанавливаю систему в VHD диски — загрузчик, начиная с Windows 7 (редакций Professional/Ultimate), прекрасно справляется с загрузкой с образа диска. Полученные таким образом диски можно спокойно использовать и в Hyper-V — убиваете сразу двоих зайцев. Не забудьте только сделать заранее копию хранилища BCD через команду bcdedit /export e:\bcd_backup.bcd.
Настраивать AD для рассылки обновлений я не захотел, поэтому просто прописал в групповых политиках путь к WSUS серверу:
Обязательно уделите внимание на порт, я из-за опечатки (8350 вместо 8530) не мог получить обновления на клиентских машинах, хотя сделано было всё верно. Так же названия пунктов в групповых политиках на Windows 7 и Windows 8 различаются.
Для получения отчета средствами WSUS необходимо дополнительно установить пакет — система уведомит вас об этом.
Так как интернета нет, то ситуация с обновлениями выходит как на скриншоте ниже:
Поведение похоже на WUApi — если обновления не прошли через них, то они не знают об этом. Поэтому данный метод снова не подходит.
Windows Management Instrumentation (WMI) в дословном переводе — инструментарий управления Windows.
WMI — реализованный корпорацией Майкрософт стандарт управления предприятием через Интернет для централизованного администрирования и слежения за работой различных частей компьютерной инфраструктуры под управлением платформы Windows. WMI является открытой унифицированной системой интерфейсов доступа к любым параметрам операционной системы, устройствам и приложениям, которые функционируют в ней.
Данный метод позволяет получить данные как с локальной машины, так и удаленно в пределах локальной сети. Для обращения к объектам WMI используется специфический язык запросов WMI Query Language (WQL), который является одной из разновидностей SQL. Получать список мы будем через WMI класс win32_quickfixengineering.
Количественно всё совпадает (даже после обновлений), поэтому было решено использовать этот метод. Для программного создания WMI запросов советую использовать следующую утилиту — WMI Delphi Code Creator. Благодаря ей я немного по другому взглянул на свой код и решил использовать заготовку из этой программы.
Полученные данные методом WMI меня не остановили, и я решился на „поверхностный реверс-инжиниринг“. Воспользуемся утилитой Process Monitor из сборника программ Sysinternals Suite для выявления файлов и ветвей реестра, которые используются при вызове выше перечисленных консольных команд и обращению к пункту „Установленные обновления“ через Панель управления.
Моё внимание привлек файл wuindex.xml, расположенный в папке C:\Windows\servicing\Packages\. Для его анализа была написана следующая программа:
К сожалению, данный файл встречается не на всех системах и принцип его генерирования и обновления остался для меня загадкой. Поэтому снова данный метод нам не подходит.
Вот мы подошли к тому, с чем связаны все эти методы. Продолжая анализ логов Process Monitor я выявил следующие папки и файлы.
Файл DataStore.edb, расположенный в папке C:\Windows\SoftwareDistribution\DataStore. Это база данных, в которой содержится история всех обновлений установленной версии Windows, включая те обновления, которые только стоят в очереди.
Для анализа файла DataStore.edb использовалась программа ESEDatabaseView. В БД существует таблица tbUpdates, содержимое которой трудно интерпретировать.
После мое внимание привлек процесс TiWorker.exe, который вызывался каждый раз при открытии пункта в Панели управления. Он „ходил“ по многим папкам, одна из которых вывела меня на верный путь.
C:\Windows\SoftwareDistribution — это папка, используемая службой обновления Windows для загрузки обновлений на компьютер с последующей их установкой, а также хранит сведения обо всех ранее установленных обновлениях.
Папка WinSxS, расположенная по адресу C:\Windows\winsxs. Это служебная папка операционной системы Windows служащая для хранения ранее установленных версий системных компонентов. Благодаря ее наличию существует возможность отката к более старой версии обновления в случае необходимости.
C:\Windows\servicing — основная составляющая всей системы, имя которой Component-Based Servicing (CBS).
CBS — обслуживание на основе компонентов, составляющая Windows, интегрированная с службой Windows Update. В противоположность обслуживанию на основе файлов File-Based Servicing (FBS) (для ОС, предшествующих Windows Vista), в котором файлы обновлялись прямо в системных директориях, в CBS появилась целая иерархия директорий и целое семейство (стек) модулей/библиотек обслуживания.
CbsApi.dll — основная библиотека поддержки технологии CBS. Не имеет открытых методов, поэтому напрямую использовать её я не смог. Microsoft использует TrustedInstaller.exe и TiWorker.exe для доступа к методам данной библиотеки и уже через эти процессы выводит нужные нам данные. Записи ведутся в C:\Windows\Logs\CBS\CBS.log.
На момент создания прототипа программы (на скриншотах можете увидеть май 2019) русскоязычной информации о CBS не было, но в конце августа нашлась очень хорошая статья в блоге — http://datadump.ru/component-based-servicing. Очень интересная статья, которая подтвердила мой опыт и собрала в себе нужную информацию. И ещё по теме: http://www.outsidethebox.ms/17988/
Вывод
Microsoft слишком усложнила тривиальную задачу по получению списка обновлений и сделала этот процесс не совсем явным. Всё это сделано для безопасности, но не для простоты использования. Соглашусь с автором статьи — в получении обновлений стали отсутствовать предсказуемость и прозрачность.
В результате исследования была написана следующая программа, демонстрацию работы которой можно увидеть в данном видео: