Что такое файлы журнала обновления windows

Обновлено: 05.07.2024

Если в предыдущих версиях ОС Windows лог файл, в котором фиксируются все этапы установки того или иного обновления, можно было посмотреть без особых трудностей – просто найдя в папке Windows системного диска файл под названием WindowsUpdate.log, то в Windows 10 данный файл отсутствует.

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

Получаем файл журнала обновлений в Windows 10

Для получения лога обновлений в операционной системе Windows 10 следует использовать встроенный в систему инструмент PowerShell. Открывается он достаточно просто: нажав на Поиск Windows и введя команду «PowerShell» (без кавычек) кликните по одноимённому пункту, что высветится выше в результатах.

И нажмите клавишу Enter, дабы команда была выполнена.

Требуемый результат достигнут.

Также вы можете посмотреть лог обновлений с использованием системного инструмента «Просмотр событий», об этом ниже.

Просматриваем файл журнала обновлений в Windows 10 с помощью «Просмотр событий»

Данный инструмент нам необходимо запустить, для этого воспользуемся всё тем же системным поиском Windows. Открыв его и введя в поисковую строку команду «eventvwr.msc» (без кавычек), кликните по высвеченному результату.

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

В свою очередь, Вы тоже можете нам очень помочь.

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

Поделившись результатами труда автора, вы окажете неоценимую помощь как ему самому, так и сайту в целом. Спасибо!

Попробуйте найти другие ответы на сайте
. или задайте вопрос в комментариях, где Вам обязательно ответят в кратчайшие сроки. (голосов: 10, средний балл: 5,00 из 5)

Помогла \ понравилась статья? Поделись ею в соцсетях!
Спасибо!

На что пойдут пожертвования \ реквизиты других платёжных систем

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

Оказавшие помощь:
Сергей И. - 500руб
<аноним> - 468руб
<аноним> - 294руб
Мария М. - 300руб
Валерий С. - 420руб
<аноним> - 600руб
Полина В. - 240руб

В следующей таблице описываются файлы журнала, созданные Windows Update.

Создание WindowsUpdate.log

Чтобы объединить и преобразовать Windows файлы трассировки (etl files) в один читаемый файл WindowsUpdate.log, см. в публикации Get-WindowsUpdateLog.

При запуске комлета Get-WindowsUpdateLog создается копия файла WindowsUpdate.log в виде статичного файла журнала. Он не обновляется как старый WindowsUpdate.log, если вы не запустите Get-WindowsUpdateLog снова.

Windows Обновление компонентов журнала

В Windows Update есть разные имена компонентов. Ниже приводится ряд наиболее распространенных компонентов, которые отображаются в файле WindowsUpdate.log:

Windows Структура журнала обновления

Структура журнала Windows обновления разделена на четыре основных удостоверения:

Отметки времени
Process ID and Thread ID
Имя компонента
Идентификаторы обновления
- Update ID and Revision Number
- Изменение ID
- Локальный ID
- Несогласованная терминология
Структура WindowsUpdate.log обсуждается в следующих разделах.

Штампы времени

Отметка времени указывает время ведения журнала.

ID процесса и нить ID

ID-данные процесса и потоковые ИД являются случайными, и они могут отличаться от журнала к журналу и даже от сеанса службы до сеанса службы в одном журнале.
- Первые четыре двузначные цифры — это код процесса.
- Следующие четыре двузначные цифры — это код потока.
- Каждый компонент, например движок usO, Windows update, вызыватели API com и Windows обработчики установщика обновления, имеет свой собственный ID процесса.
Имя компонента

Поиск и определение компонентов, связанных с идентификацией. Различные части Windows обновления имеют разные имена компонентов. Некоторые из них являются следующими:
- ProtocolTalker — синхронизация с клиентом-сервером
- DownloadManager — создает и отслеживает загрузки полезной нагрузки
- Обработчик, установка - обработчики установки (CBS и т.д.)
- EEHandler — оценка правил применимости к обновлению
- DataStore — локальное обновление данных кэшинга
- IdleTimer — отслеживание активных вызовов, остановка службы
Идентификаторы обновления

Update ID and revision number

Существуют различные идентификаторы для одного и того же обновления в разных контекстах. Важно знать схемы идентификаторов.
- Update ID: GUID (указанный на предыдущем скриншоте), который назначен заданным обновлениям во время публикации
- Номер версии. Число, приращенное каждый раз при внесении изменения и переопубликовки данного обновления (с заданным ИД обновления) в службе.
- Номера версий повторно будут повторноиспользоваться из одного обновления в другое (а не уникальный идентификатор).
- ID обновления и номер ревизии часто показаны вместе как ".revision".
Изменение ID
- Update ID (не путайте это значение с "номером ревизии") — это серийный номер, который выдается при первоначальном опубликовании или исправлении обновления в данной службе.
- В обновленном обновлении сохраняется один и тот же ID обновления (GUID), увеличивается число его изменений (например, от 100 до 101), но он получает новый ИД,не связанный с предыдущим ID.
- Коды ревизии уникальны для данного источника обновления, но не для нескольких источников.
- Один и тот же вариант обновления может иметь различные ID-версии Windows и WSUS.
- Один и тот же ID-версии может представлять различные обновления Windows Update и WSUS.
Локальный ID
- Локальный ID — это серийный номер, который выдается при получении обновления от службы клиентом Windows Обновления
- Обычно в журналах отключки, особенно с использованием локального кэша для обновления информации (Datastore)
- Различные клиентские компьютеры назначят разные локальные ID-документы одному обновлению
- Локальные ID,которые клиент использует, можно найти, получив файл %WINDIR%\SoftwareDistribution\Datastore\Datastore.edb
Несогласованная терминология

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

Распознавание ID-данных по форме и контексту:
- GUID — это обновленные ID-интерфейсы
- Небольшие integers, которые отображаются рядом с обновлением ID являются номерами ревизии
- Крупные integers, как правило, являются ID-версии
- Небольшие наборы (особенно в Datastore) могут быть локальными Windows
Windows Настройка анализа файлов журналов с помощью средства SetupDiag

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

Что за файлы?

Можно ли удалить эти файлы?

Будто операционка и не обновлялась:

Как очистить?

Все просто, сперва запустите командную строку от имени администратора, варианты как это можно сделать:
1. Нажмите правой кнопкой по Пуск и выберите пункт Windows Powershell (Администратор), потом введите cmd и нажмите ОК. При таком варианте командная строка будет сразу прямо в окошке Powershell.
2. Откройте диспетчер задач, в левом верхнем углу выберите Файл > укажите cmd, а внизу поставьте галочку создать задачу с правами админа.
3. Нажмите просто правой кнопкой по пуску и выберите Командная строка (Администратор). Этот пункт может отсутствовать на некоторых версиях Windows 10.
net stop wuauserv

net start wuauserv

Откройте окно Параметры (Win + I), далее перейдите в Система > Память устройства (или просто Память) > выбираем Освободить место сейчас:

Но пункт Освободить место сейчас может и отсутствовать, а вместо него может быть раздел Временные файлы:

Тогда выбираем Временные файлы. В итоге у вас будет окошко, где можно удалить Файлы журнала обновления Windows:

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

Добавить комментарий Отменить ответ

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

Вы когда-нибудь задумывались, с помощью чего формируется список установленных обновлений Windows? А через какое API его достать? Ответы на эти и другие возникающие вопросы я постараюсь дать в своём небольшом исследовании.

Предыстория или с чего всё началось.

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

Раньше на каждое «ТО» с помощью WSUS подтягивались все выпущенные обновления и распространялись на все машины. Также периодически выходили ТСБ (технические сервисные бюллетени), в которых указывалось, что требуется установить необходимые обновления в виде изолированных пакетов. В итоге у нас накапливаются обновления, которые в WSUS отследить нельзя, а можно было увидеть только через панель управления в разделе «Установленные обновления».

Бывают ситуации, когда АРМ или сервер «падает» и приходится его восстанавливать из образа, созданного некоторое время назад. При восстановлении из образа есть вероятность того, что мы можем потерять нужные нам обновления (которые пришли в виде изолированных пакетов), которые устанавливались до падения машины. Объяснил максимально подробно насколько мог, потому что уточнения будут уже коммерческой тайной.

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

Консольные команды

Начнем с простого и воспользуемся тем, что предлагает нам Windows без использования сторонних средств. Это можно сделать с помощью следующих команд:
- wmic qfe list
- systeminfo
- dism /online /get-packages
- через PowerShell:
- Get-HotFix
- Get-SilWindowsUpdate (доступно только в серверных редакциях)
- Get-WmiObject -Class win32_quickfixengineering — через доступ к WMI классу win32_quickfixengineering (о WMI чуть позже)
Получить список через графический интерфейс можно через стандартный пункт Панели управления «Установка/удаление программ», но скопировать оттуда мы ничего не можем. Каждый инструмент панели управления представлен файлом .cpl в папке Windows\System. Файлы .cpl в системную папку Windows автоматически загружаются при запуске панели управления. За пункт Программы отвечает файл Appwiz.cpl. Его анализ ни к чему не привел.

Формально все методы получения списка обновлений можно разделить на две группы: локальные и сетевые.

Все методы проверялись на чистых образах систем (Windows 7, 8, Server 2012 R2) с интегрированными обновлениями, после каждого обновления через Центр обновления с официальных серверов Microsoft проводилась дополнительная проверка. Остановимся на каждом из них подробнее.

WUApi (Windows Update Agent API) — использование API агента обновления Windows. Самый явный вариант, название которого говорит само за себя. Использовать для этого будем библиотеку Wuapi.dll.

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

Есть и вторая вариация этого метода: Update Session — получение информации с помощью подключения к сессии обновления Windows Update Agent (в данном случае работаем не напрямую с библиотекой).

Microsoft подсказывает об удаленном использовании API.

Главный минусы этих двух методов — не позволяют найти исправления KB, которые не распространяются через Центр обновления Windows. Можно увидеть только то, что прошло через сам агент обновления, то есть данный вариант нас не устраивает.

Система обслуживания образов развертывания и управления ими (Deployment Image Servicing and Management) — это средство командной строки, которое может использоваться для обслуживания образа Windows или для подготовки образа среды предустановки Windows (Windows PE). Является заменой диспетчера пакетов (Pkgmgr.exe), PEimg и Intlcfg.

Данная утилита используется для интеграции обновлений, сервис паков в образ системы. Обновления Windows представляют собой отдельные модули, которые могут быть представлены в нескольких вариантах:
- .cab-файлы (Cabinet) — архивы. Предназначены для распространения и установки при помощи модулей Центра обновлений Windows в автоматизированном режиме;
- .msu-файлы (Microsoft Update Standalone Package) — исполняемые файлы. Предназначены для распространения и установки самими пользователями в ручном режиме через каталог обновлений Microsoft. Фактически представляют собой упакованный набор, состоящий из .cab-, .xml, .txt-файлов.
Количество обновлений совпадало с количеством из списка Панели управления до первого апдейта через центр управления — после него количество обновлений стало меньше (было 214, стало 209), хотя по логике они должны были увеличиться. Примеры вывода До обновления, После обновления.

С чем это связано я могу только предполагать — возможно, какие-то обновления замещали предыдущие, следовательно, и количество стало меньше.

Чуть позже я наткнулся на утилиту от китайцев DISM++, которая основана не на DISM API или DISM Core API, но имеющиеся в ней библиотеки не имеют нужных мне открытых методов, поэтому я забросил эту идею и продолжил поиски дальше.

Windows Server Update Services (WSUS) — сервер обновлений операционных систем и продуктов Microsoft. Сервер обновлений синхронизируется с сайтом Microsoft, скачивая обновления, которые могут быть распространены внутри корпоративной локальной сети. Опять же специальный инструмент, предназначенный для работы с обновлениями.

Распространяется только на серверных редакциях ОС Windows, поэтому был развернут следующий стенд:
- основная система – Windows Server 2016;
- а через систему виртуализации Hyper-V были развернуты две клиентские ОС:
  - Windows 8.1
  - Windows 7
  Чтобы не выделять раздел жесткого диска для новой системы я пользуюсь 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.
  
  Вывод
  
  Microsoft слишком усложнила тривиальную задачу по получению списка обновлений и сделала этот процесс не совсем явным. Всё это сделано для безопасности, но не для простоты использования. Соглашусь с автором статьи — в получении обновлений стали отсутствовать предсказуемость и прозрачность.
  
  В результате исследования была написана следующая программа, демонстрацию работы которой можно увидеть в данном видео:
  
  Читайте также: