Windows update logs are now generated using etw event tracing for windows
Быстрый анализ ошибок обновления Windows
Точно неизвестно, какое количество пользователей и системных администраторов сталкиваются с проблемами обновления на компьютерах Windows постоянно или периодически.
Проблемы обновления могут быть крайне раздражительными, особенно если система переходит в циклические состояния постоянной загрузки, установки, перезагрузки и отката изменений.
Ранее Microsoft выпустила несколько некорректных обновлений, которые вызвали проблемы на машинах Windows 10. Самыми известными, пожалуй, являются KB3081424 и KB3194496, который вызвали ошибки на компьютерах по всему миру.
На сайте Microsoft Technet доступна утилита Reset Windows Update Agent, разработанная специально для исправления распространенных проблем обновления. Инструмент успешно справляется с проблемами работы центра обновления Windows, но не сможет помочь, если проблема вызвана на стороне Microsoft.
Быстрая проверка ошибок обновления Windows
Быстрая проверка ошибок обновления Windows» />
Windows сохраняет журнал обновлений, который содержит все события, связанные с обновлением. Эти журналы можно найти по пути C:\Windows\Logs\WindowsUpdate. Логи имеют формат ETW (Event Trace for Windows) и могут быть проанализированы с помощью специализированных инструментов.
Пользователь может также использовать простую команду PowerShell, чтобы преобразовать файлы Event Trace в простой текст, который можно исследовать на предмет ошибок и проблем, связанных с обновлением Windows.
Преобразование журнала обновления:
Затем начнется парсинг файлов Event Trace, который может занять некоторое время, зависящее от количества и размеров файлов журналов.
После этого на рабочем столе появится файл WindowsUpdate.log. Размер файла может достигать нескольких мегабайт. Файл можно открыть в любом текстовом редакторе, например, в Notepad++.
Быстрая проверка ошибок обновления Windows» />
Можно исследовать файл по строкам, а можно немного ускорить процесс:
Несмотря на то, что анализ журнала обновления Windows может занять приличное время, то может быть один из самых лучших способов определить причину сбоя обновления. К тому же, компания Microsoft представила руководство по исправлению ошибок обновления Windows 10, которое также может помочь в решении найденных проблем.
А что вы предпринимаете в случае сбоя обновления Windows?
Файлы журнала Центра обновления Windows Windows Update log files
Применимо к: Windows10 Applies to: Windows 10
В следующей таблице описаны файлы журналов, созданные Windows Update. The following table describes the log files created by Windows Update.
Создание WindowsUpdate.log Generating WindowsUpdate.log
Чтобы объединить и преобразовать файлы трассировки Windows Update (.etl files) в один читаемый файл WindowsUpdate.log, см. в материале Get-WindowsUpdateLog. To merge and convert Windows Update trace files (.etl files) into a single readable WindowsUpdate.log file, see Get-WindowsUpdateLog.
При запуске комлета Get-WindowsUpdateLog создается копия файла WindowsUpdate.log в виде статичного файла журнала. When you run the Get-WindowsUpdateLog cmdlet, an copy of WindowsUpdate.log file is created as a static log file. Он не обновляется как старый WindowsUpdate.log, если вы не запустите Get-WindowsUpdateLog снова. It does not update as the old WindowsUpdate.log unless you run Get-WindowsUpdateLog again.
Компоненты журнала обновления Windows Windows Update log components
В движке Обновления Windows есть разные имена компонентов. The Windows Update engine has different component names. Ниже приводится ряд наиболее распространенных компонентов, которые отображаются в файле WindowsUpdate.log: The following are some of the most common components that appear in the WindowsUpdate.log file:
Многие сообщения журнала компонентов неоценимы, если вы ищете проблемы в этой области. Many component log messages are invaluable if you are looking for problems in that specific area. Однако они могут быть бесполезными, если не фильтровать, чтобы исключить нерелевантные компоненты, чтобы можно было сосредоточиться на важных компонентах. However, they can be useless if you don’t filter to exclude irrelevant components so that you can focus on what’s important.
Структура журнала обновления Windows Windows Update log structure
Структура журнала обновления Windows разделена на четыре основных удостоверения: The Windows update log structure is separated into four main identities:
Структура WindowsUpdate.log обсуждается в следующих разделах. The WindowsUpdate.log structure is discussed in the following sections.
Штампы времени Time stamps
Отметка времени указывает время ведения журнала. The time stamp indicates the time at which the logging occurs.
ID процесса и нить ID Process ID and thread ID
ID-данные процесса и потоковые ИД являются случайными, и они могут отличаться от журнала к журналу и даже от сеанса службы до сеанса службы в одном журнале. The Process IDs and Thread IDs are random, and they can vary from log to log and even from service session to service session within the same log.
Имя компонента Component name
Поиск и определение компонентов, связанных с идентификацией. Search for and identify the components that are associated with the IDs. Различные части двигателя обновления Windows имеют разные имена компонентов. Different parts of the Windows Update engine have different component names. Некоторые из них являются следующими: Some of them are as follows:
Идентификаторы обновления Update identifiers
Update ID and revision number Update ID and revision number
Существуют различные идентификаторы для одного и того же обновления в разных контекстах. There are different identifiers for the same update in different contexts. Важно знать схемы идентификаторов. It’s important to know the identifier schemes.
Изменение ID Revision ID
Локальный ID Local ID
Несогласованная терминология Inconsistent terminology
Иногда журналы используют термины несогласованно. Sometimes the logs use terms inconsistently. Например, в списке InstalledNonLeafUpdateIDs фактически содержатся измененные ИД, а не обновленные. For example, the InstalledNonLeafUpdateIDs list actually contains revision IDs, not update IDs.
Распознавание ID-данных по форме и контексту: Recognize IDs by form and context:
Анализ файлов журнала установки Windows с помощью средства SetupDiag Windows Setup log files analysis using SetupDiag tool
SetupDiag — это диагностический инструмент, который можно использовать для анализа журналов, связанных с установкой обновлений Windows. SetupDiag is a diagnostic tool that can be used for analysis of logs related to installation of Windows Updates. Подробные сведения см. в инструкции SetupDiag. For detailed information, see SetupDiag.
Просмотр журнала обновлений WindowsUpdate.log в Windows 10 / Windows Server 2016
Исторически для анализа работы агента и службы обновления Windows используется текстовый файл WindowsUpdate.log. Однако в Windows 10 (Windows Server 2016/2019) вместо привычного текстового файла логи Windows Update ведутся в формате Event Tracing for Windows (ETW). За счет этого увеличивается быстродействие подсистемы записи логов и экономится место на диске.
Таким образом, события Windows Update теперь больше не записываются в реальном времени в файл %windir%\WindowsUpdate.log. И хотя сам файл все еще присутствует в корне папки Windows, в нем лишь указано, что для сбора логов теперь применяется формат ETW.
Главное неудобство для администраторов – теперь вы не можете быстро проанализировать текстовый файл WindowsUpdate.log, найти ошибки в службе агента обновлений Windows (см. полный список ошибок Windows Update), проверить настройки WSUS и проанализировать историю установки обновлений.
Вы можете сконвертировать события ETW в привычный текстовый формат WindowsUpdate.log для более удобного анализа событий службы обновлений. Для этого используется командлет PowerShell — Get-WindowsUpdateLog. Данный командлет позволяет собрать информацию со всех .etl файлов (хранятся в каталоге C:\WINDOWS\Logs\WindowsUpdate) и сформировать один файл WindowsUpdate.log.
Чтобы сформировать файл WindowsUpdate.log и поместить его в каталог C:\PS\Logs, выполните следующую команду в консоли PowerShell:
Файл “C:\Program Files\Windows Defender\SymSrv.dll” обычно отсутствует, если на сервере не установлен антивирус Windows Defender.
Чтобы исправить ошибку, вы можете установить Defender, скопировать файл SymSrv.dll с другого Windows Server 2016/ Windows 10 или поиском найти его в каталоге “C:\Windows\WinSxS\” (у меня каталог назывался C:\Windows\WinSxS\amd64_windows-defender-service-cloudclean_…) и скопировать его в папку C:\Program Files\Windows Defender.
В старых версиях Windows 10 при первом запуске командлет Get-WindowsUpdateLog скачает и установит сервер символов Microsoft (Microsoft Internet Symbol Store). В последних версиях Windows 10 выполняется онлайн доступ к серверу символов Microsoft в Azure. Затем командлет:
Это значит, что у вас не установлен сервер символов Windows Symbol (сейчас нельзя скачать отдельную программу установки Windows symbols, т.к. они автоматически загружаются из хранилища символов в Azure). Для изолированных сред вы можете использовать офлайн версию сервера символов согласно статье Offline Symbols for Windows Update.
Откройте файл журнала с помощью такой команды PowerShell:
Анализировать получившийся файл WindowsUpdate.log довольно сложно, т.к. в нем собираются данные из множества источников:
Вы можете выбрать последние 30 событий от агента обновления Windows (agent) с помощью простого регулярного выражения:
Можно отфильтровать события в логе по нескольким источникам:
Аналогично вы можете искать события по номеру KB, ошибка (строки FAILED, Exit Code, FATAL).
Также вы можете сформировать файл WindowsUpdate.log для удаленного компьютера/сервера:
Event Tracing for Windows на стороне зла. Но это не точно
В предыдущих статьях про сниффер на PowerShell и сбор данных о загрузке с удаленного сервера я уже немного писал про возможности ETW (Event Tracing for Windows). Сегодня я хочу подробнее рассказать про эту технологию.
Заодно покажу на примере разбора HTTPS и создания кейлоггера на PowerShell, как ее можно использовать во благо. Или не совсем во благо.
Работа с ETW
Event Tracing for Windows собирает и передает сообщения от системных компонентов Windows и сторонних приложений. Появился он еще во времена Windows 2000, но если в те времена системных провайдеров было несколько десятков, то сейчас их счет идет уже на сотни. Сообщения удобно использовать для диагностики ошибок и решения проблем с производительностью софта.
Часть системных провайдеров по умолчанию уже пишет в журнал событий Windows, а часть включается отдельно. Так что даже если вы не знаете про ETW, наверняка им пользуетесь. Познакомиться с журналами и включить часть из них при необходимости можно в стандартном просмотре событий в журналах приложений и служб. Немного о журнале и о работе с ним можно почитать в статье «Вертим логи как хотим ― анализ журналов в системах Windows».
Посмотреть список существующих провайдеров, которые только и рады поведать нам, что с ними происходит, можно командой logman query providers.
Список провайдеров, подключенных к обычному блокноту.
Подписку на события определенного провайдера или на трассировку можно включить через PowerShell при помощи командлета New-NetEventSession. А можно и вовсе накликать мышкой по пути «Управление компьютером» — «Производительность» — «Группы сборщиков данных». Здесь в сеансах отслеживания событий видно, какие трассировки запущены, и при желании можно создать свой сборщик.
Просматривать результат можно при помощи утилит и наборов утилит типа Microsoft Message Analyzer, Windows Performance Toolkit или вовсе командлетом PowerShell Get-WinEvent.
С особенностями работы ETW я рекомендую ознакомиться в документации Microsoft, начать можно с раздела About Event Tracing. Также могу порекомендовать неплохой материал «Изучаем ETW и извлекаем профиты».
Поскольку ETW работает на уровне ядра, то его отличает скорость передачи сообщений и отсутствие необходимости устанавливать какие-либо драйверы или инжекты в приложения. Обычно ETW используют для диагностики производительности и проблем с приложениями. Например, в статье «Ускорение загрузки Windows for fun and profit» анализируются факторы, влияющие на замедление загрузки, а в материале 24-core CPU and I can’t move my mouse — причины торможения Windows на рядовых операциях. Приведу пример — анализ запуска командлетов PowerShell.
Следим за PowerShell
Предположим, что вы каким-то образом (например, через аудит запуска процессов) обнаружили, что на компьютере запускаются невнятные процессы и скрипты PowerShell. Одной из методик будет использование ETW для анализа их активности. Например, посмотрим на провайдера PowerShell. Включим трассировку командой:
Теперь подождем, пока непонятные скрипты отработают, остановим трассировку командой:
Теперь можно посмотреть трассировку, например, через Microsoft Message Analyzer.
Подозрительный clean.ps1 явно что-то ищет и удаляет.
Если выбрать нужную строку, то в нижней панели будет расширенная информация о событии.
А, это же скрипт для очистки кэша 1С!
В этот раз все оказалось банально. Но в более сложных случаях можно запустить трассировку и для проверки других активностей:
Таким образом, ETW может помочь поймать зловреда и разобраться в работе приложений. Местами это информативнее, чем привычный Process Monitor. Но помимо дел добрых, у механизма есть и «темная» сторона.
Приведу пару примеров в качестве Proof-of-Concept
S — значит бееезопасно
В этом примере я покажу, как легко узнать, что же ищет пользователь в интернете, даже по HTTPS. Посмотреть можно и без PowerShell — только мышка, только хардкор. В нашей задаче будет пользователь, будет Windows, Internet Explorer и журнал событий.
Начнем с того, что включим журнал событий Wininet. Делается это так: открываем журнал событий, на вкладке «Вид» включаем отображение аналитических и отладочных журналов.
Добавляем отображение нужных журналов.
После этого включаем UsageLog в контекстном меню, и этого достаточно для получения нужной информации. Попользуемся IE и посмотрим лог:
Собственно, в журнале видны заголовки и непосредственный запрос в поисковую систему.
Помимо заголовков при помощи журнала можно вытащить и cookie, а заодно посмотреть POST-запросы — например, для вытаскивания учетных данных. Методика работает на любых приложениях, использующих wininet.dll для работы с интернетом. К примеру, браузер Edge.
То же самое запросто реализуется и на PowerShell, и даже на cmd. Приведу пример реализации последним.
Для начала создадим трассировку:
Теперь поработаем в браузере, проверим почту. Трассировку можно после этого остановить командой:
Простейший анализ можно провести при помощи командной утилиты wevtutil.exe. Например, для просмотра POST-запросов команда будет такой:
Можно даже наудачу попробовать поискать по слову password и получить результат.
Пароли открытым текстом. Очень напрягает.
Стоит отметить, что антивирус при этом молчал. Действительно, ведь это обычный процесс трассировки.
Разумеется, события WinInet можно использовать и для диагностики неполадок вроде «почему этот сайт не открывается и что вообще происходит». Но тем не менее, возможности довольно интересны. Перейду к еще более закрученному примеру.
Кейлоггер на PowerShell. Потому что могу.
В Windows есть два интересных провайдера ETW:
Microsoft-Windows-USB-UCX (36DA592D-E43A-4E28-AF6F-4BC57C5A11E8) — работает с USB 2.0.
Microsoft-Windows-USB-USBPORT (C88A4EF5-D048-4013-9408-E04B7DB2814A) — работает с USB 3.0.
С их помощью можно получить данные HID, которые передает такое устройство USB, как клавиатура или мышь. Данные захватываются в сыром виде, но благодаря спецификации HID их вполне можно привести к читаемому виду.
Для начала трассировки достаточно выполнить следующие команды:
А данные можно получить командлетом PowerShell:
Приведу пример простого скрипта, который читает данные трассировки и преображает их в читаемые значения. Преобразование делается только для английских букв и исключительно в заглавные.
При запуске скрипт включает трассировку на 10 секунд, затем показывает результат.
Результат работы скрипта.
Конечно же, разобравшись с данными HID, можно доработать скрипт до полноценного кейлоггера, который записывал бы данные с клавиатуры и мыши. Стоит отметить и ограничения этого механизма:
Зато никаких драйверов и перехватчиков. Ну, и конечно, помимо зловредного использования такой кейлоггер может помочь в диагностике проблем с клавиатурой. Теоретически.
Нужно ли бояться
Даже встроенные механизмы в руках злодея могут натворить бед. Методы защиты остаются те же самые: блокировать исполняемые файлы не из системных каталогов, не работать под пользователем с правами администратора, а если и работать — то хотя бы не отключать UAC. И, конечно же, встроенные браузеры Windows по части безопасности вызывают вопросы.
Изучаем Event Tracing for Windows: теория и практика
Добрый день. Недавно мне необходимо было разобраться со службой трассировки Windows. Эта служба появилась еще в Windows 2000, однако статей по этой службе в интернете оказалось крайне мало.Так появилась идея написания этой статьи. Итак, начнем!
Сегодня я попытаюсь рассказать про:
Теоретические основы службы трассировки Windows
Event Tracing for Windows (ETW) — это служба, которая позволяет получать события от одного или нескольких поставщиков событий в режиме реального времени или из файла *.etl за некоторый временной период. Не понятно? Сейчас разберемся!
Для того, чтобы понять принцип работы ETW, необходимо разобраться со структурой этой службы
Архитектура ETW включает в себя 4 элемента
В системе зарегистрировано некоторое число поставщиков событий, т.е. приложений, которые могут делиться своими событиями с сессиями ETW. Так же в этой системе есть некоторое число активных сессий ETW, которые могут потреблять события от одного или нескольких поставщиков и предоставлять их пользователю либо в режиме реального времени, либо записывать все события от поставщиков в файл логирования (*.etl). И управляют всем этим движением контроллеры.
А теперь рассмотрим каждый элемент рассмотренной выше архитектуры подробнее, чтобы окончательно разобраться с принципом работы!
Поставщики событий (providers)
Поставщики событий — это приложения, содержащие инструменты отслеживания событий. После того, как поставщик зарегистрировался, контроллер может включить или отключить отслеживание событий в поставщике. Поставщик определяет свою интерпретацию включения или выключения. Как правило, включенный поставщик генерирует события, а отключенный поставщик нет. Это позволяет добавлять отслеживание событий в наше приложение, не требуя, чтобы оно генерировало события все время.
Один поставщик может делиться своими событиями сразу с несколькими сессиями ETW.
Каждое событие состоит из двух элементов: заголовка и данных! Заголовок события включает информацию о событии: идентификатор провайдера, идентификатор события, временную метку и т.д. Остальные данные определяются конкретным провайдером: ETW принимает любые данные и записывает их в буфер, а их интерпретация возлагается на потребителей информации.
Существует четыре основных типа провайдеров:
поставщики MOF (классические)
провайдеры WPP
провайдеры на основе манифеста
провайдеры TraceLogging.
Поставщики событий различаются по типам полей, которые они хранят в полезных нагрузках событий.
С поставщиками событий вроде разобрались. Идем дальше!
Контроллеры
Контроллер — это приложение, которое отвечает за функционирование одной или нескольких сессий ETW. Именно контроллер определяет размер и местоположение файла журнала, запускает и останавливает сеансы трассировки событий (сессии ETW), позволяют поставщикам регистрировать события в сеансе. Как уже было сказано ранее, именно контроллер разрешает провайдеру делиться своими событиями!
Потребители
Потребители — это приложения, которые получают и обрабатывают события от одного или нескольких сеансов трассировки одновременно. Потребители могут получать события, хранящиеся в файлах журналов или из сеансов, которые доставляют события в режиме реального времени. Как мы уже знаем, у одной сессии ETW может быть несколько поставщиков. Возникает вопрос: а не будет ли путаницы? Как события из различных сессий ETW будут располагаться друг относительно друга? События сортируются по времени их появления, т.е. система доставляет события в хронологическом порядке!
Сессии ETW
Сеансы отслеживания событий (сессии ETW) записывают события от одного или нескольких провайдеров, которые разрешает контроллер. Сессия также отвечает за управление и очистку буферов.
Трассировка событий поддерживает до 64 сеансов трассировки событий, выполняющихся одновременно. Из этих сессий есть две сессии специального назначения. Остальные сеансы доступны для общего пользования. Две сессии специального назначения:
Итак, а теперь переходим к практике.
Создание своей сессии ETW
Перед началом работы нам потребуется знание нескольких утилит, а именно:
список провайдеров, доступных на конкретной ОС
получить полную информацию о провайдере
список всех активный сессий ETW
Так же, для просмотра файлов, желательно иметь Notepad++.
Просмотрев список провайдеров на своем компьютере (а их более 1000 на Windows 10), выберем один из них для нашей сессии:
Я выбрал Microsoft-Windows-WinINet (эта служба записывает все наши действия при работе в браузере Microsoft Edge).
9. Добавляем интересующие нас провайдеры в сессию
10. Указываем интересующие нас ключевые слова в поле «Keywords(Any)» («Ключевые слова(Любые)») — 0xFFFFFFFFFFFFFFFF
11. Указываем уровень логирования 0xFF
=
12. Выбираем путь, по которому будет сохраняться файл журнала сессии
13. Выбираем флажок «Start this data collector set now» («Запустить группу сборщиков данных сейчас»)
Теперь созданная нами сессия работает. Необходимо поработать некоторое время в Microsoft Edge, чтобы сессия собрала о нас информацию!
После того, как прошло некоторое время переходим в место, куда мы сохранили файл логирования. Там выполняем следующую команду.
После выполнения этой команды сформируется 4 файла.
Нас в данный момент будет интересовать dumpfile.xml. Открывать этот файл можно либо через notepad++, можно также сделать это в Excel.
Внимательно изучив этот файл, можно заметить, что данная сессия собрала почти всю информацию о нашем перемещении в сети интернет. Более подробно об этом можно почитать здесь Изучаем ETW и извлекаем профиты.
Ну что же, а мы движемся дальше. Только что мы создали сессию с единственным поставщиком событий. Получили данные сессии из файла логирования. Пришло время кодить!
Использование event tracing API для работы с ETW
В этой статье Вы найдете ответы на многие вопросы, которые у вас скорее всего возникнут при написании приложений!
Начнем с самого простого.
Настройка и запуск сеанса отслеживания событий
Для начала рассмотрим общую идею.
Чтобы запустить сеанс трассировки необходимо:
1) Задать структуру EVENT_TRACE_PROPERTIES
2) Запустить сеанс с помощью StartTrace
Далее необходимо включить поставщиков событий
3) Включаем поставщиков с помощью EnableTrace | EnableTraceEx | EnableTraceEx2
Чтобы остановить сеанс трассировки необходимо:
4) Перед остановкой сеанса трассировки необходимо отключить провайдеров с помощью EnableTrace | EnableTraceEx | EnableTraceEx2, передав EVENT_CONTROL_CODE_DISABLE_PROVIDER
5) Вызвать функцию ControlTrace и передать ей EVENT_TRACE_CONTROL_STOP
В приведенном ниже примере я создаю сессию с именем MyEventTraceSession. Файл журнала логирования находится в текущей директории и называется WriteThePuth.etl
Поставщиком событий является Microsoft-Windows-Kernel-Process. Его GUID Вы можете узнать с помощью
Разберем приведенную программу более подробно.
1) Задаем структуру EVENT_TRACE_PROPERTIES
Чтобы настроить сеанс трассировки событий, необходимо использовать структуру EVENT_TRACE_PROPERTIES, чтобы указать свойства сеанса. Память, которую вы выделяете для структуры EVENT_TRACE_PROPERTIES, должна быть достаточно большой, чтобы также содержать имена файлов сеансов и журналов, которые следуют за структурой в памяти.
2) Запускаем сеанс с помощью StartTrace
После того, как вы укажете свойства сеанса, вызовите функцию StartTrace, чтобы запустить сеанс. Если функция завершается успешно, параметр SessionHandle будет содержать дескриптор сеанса, а свойство LoggerNameOffset будет содержать смещение имени сеанса.
3) Включаем поставщиков с помощью EnableTrace | EnableTraceEx | EnableTraceEx2
Чтобы включить поставщиков, которым вы хотите разрешить записывать события в свой сеанс, вызовите функцию EnableTrace, чтобы включить классических поставщиков, и функцию EnableTraceEx, чтобы включить поставщиков на основе манифеста. В остальных случаях — EnableTraceEx2.
4) Перед остановкой сеанса трассировки необходимо отключить провайдеров с помощью EnableTrace | EnableTraceEx | EnableTraceEx2, передав EVENT_CONTROL_CODE_DISABLE_PROVIDER
Чтобы остановить сеанс трассировки после сбора событий, вызовите функцию ControlTrace и передайте EVENT_TRACE_CONTROL_STOP в качестве управляющего кода. Чтобы указать сеанс для остановки, вы можете передать дескриптор сеанса трассировки событий, полученный из более раннего вызова функции StartTrace, или имя ранее запущенного сеанса. Обязательно отключите всех провайдеров перед остановкой сеанса. Если вы остановите сеанс перед первым отключением провайдера, ETW отключит провайдера и попытается вызвать контрольную функцию обратного вызова провайдера. Если приложение, запустившее сеанс, завершается без отключения поставщика или вызова функции ControlTrace, поставщик остается включенным.
5) Чтобы остановить сеанс трассировки, вызываем функцию ControlTrace и передаем ей EVENT_TRACE_CONTROL_STOP
Как мы убедились на приведенном выше примере, использование Event Tracing API является не самым простым. В зависимости от того, чем вы занимаетесь, дальше можно заниматься либо написание поставщиков событий, либо написанием потребителей событий. Однако обе эти задачи довольно объемные и в этой статье рассматриваться не будут! Дополнительную сложность создают 4 вида поставщиков событий, и, соответственно, 4 варианта написания событий и 4 варианта их потребления. Очень подробно и хорошо работа с Event Tracing API описана на официальном сайте Microsoft Using Event Tracing
Проработав некоторое время с Event Tracing API у меня появился вопрос: а есть ли утилиты, которые упросят мне жизнь?
Использование tracerpt и xperf для работы с ETW
В этой главе я не буду рассматривать эти утилиты с теоретической точки зрения.
Команду Tracerpt можно использовать для анализа журналов трассировки событий, файлов журналов, созданных монитором производительности, и поставщиков трассировки событий в реальном времени. Он создает файлы дампа, файлы отчетов и схемы отчетов. У этой утилиты большое количество параметров, однако для начала работы подойдет следующий «минимум»
Утилита xperf.exe является полноценным контроллером. Она поддерживает аргументы командной строки, позволяющие управлять ETW-провайдерами и сессиями. Контроллеры могут запрашивать состояние активных в данный момент сессий и получать списки всех зарегистрированных в системе провайдеров. Например, для получения всех активных сессий следует использовать следующую команду:
а для получения списка всех зарегистрированных в системе провайдеров — команду:
Контроллеры обладают еще несколькими ключевыми функциями. Они могут обновлять сессии и сбрасывать содержимое буферов на диск.
К сожалению, в данной статье я не затронул некоторое количество интересных вопросов (например, потребление событий в режиме реального времени или работу с сессиями специального назначения).
Об этом можно почитать на следующих сайтах: