screen on power study trace session что это
Вадим Стеркин
Составить полное представление о загрузке Windows можно с помощью набора Windows Performance Toolkit. Утилиты командной строки xbootmgr и xperf позволяют создать подробный отчет о запуске системы и представить его в графическом и текстовом виде для всестороннего анализа загрузки.
Эта статья продолжает серию материалов о загрузке Windows. Вы уже знаете, как получить подробный отчет о загрузке и устранить основные системные проблемы, а также ускорить загрузку системы, не прилагая особых усилий. Вы также познакомились со способом диагностики загрузки с помощью журнала событий. Я уверен, что после изучения этих статей и применения полученных знаний на практике ваша система стала загружаться быстрее.
Однако эти простые способы не позволяют выявить скрытые факторы или проблемы, замедляющие загрузку Windows. Теперь настало время познакомиться поближе со всеми этапами загрузки Windows и провести их детальный анализ с помощью Windows Performance Toolkit (WPT).
[+] Сегодня в программе
Загрузка и установка WPT
С выходом каждой новой Windows обновляются средства для анализа производительности Windows, поэтому я рекомендую использовать Windows Performance Analyzer (WPA) из Windows ADK для диагностики загрузки всех поддерживаемых ОС Windows. Краткое руководство по работе с WPA включено в статью об изучении автозагрузки Windows. Изложенные далее сведения об этапах загрузки применимы ко всем поддерживаемым ОС Windows.
Поскольку набор Windows Performance Toolkit 4.7 для Windows 7 и Vista недоступен для отдельной загрузки, этому вопросу придется уделить чуть больше внимания, чем обычно. Самый простой и экономичный с точки зрения трафика способ – это скачать его с помощью веб-установщика Windows 7 SDK. Пройдя все приветственные окна установщика, вы увидите страницу с выбором компонентов.
Здесь нужно снять все флажки кроме одного, показанного на рисунке и продолжить установку.
Решения некоторых проблем с установкой SDK вы найдете здесь.
Вы, наверное, обратили внимание, что WPT присутствует в двух узлах. Если вам нужны пакеты MSI, их можно скачать, отметив флажок в узле Redistributable Packages. После установки вы найдете пакеты для различных архитектур в папке Program Files\Microsoft SDKs\Windows\v7.1\Redist. Если вы выбрали только этот вариант (вместо рекомендуемого выше), запустите установку двойным щелчком по MSI-пакету.
Подготовка к работе
Следуя трем простым правилам, вы застрахуете себя от возможных проблем, обеспечите правильную работу всех команд и точно измерите длительность загрузки.
Все команды выполняйте в командной строке, запущенной от имени администратора. Там же можно добавить в меню пункт для ее запуска в нужной папке – пригодится.
Сбор данных
Все логи загрузки лучше хранить в одной папке, допустим, C:\Trace. Откройте командную строку с полными правами и введите:
Здесь и далее я буду использовать пути применительно к этой папке и стандартной установке WPT в 32-разрядной Windows 7. При необходимости изменяйте пути на свои.
Закройте все программы и сохраните все документы. Процесс сбора данных о загрузке системы запускается одной командой:
Аналогичные команды можно использовать для диагностики
гибернации:
выключения:
Примечание. Если при выполнении команд вы видите сообщение «xbootmgr не является внутренней или внешней командой», установка была неудачной. Вы найдете решение в этой теме форума.
Вернемся к загрузке, однако. Компьютер будет перезагружен. Если после входа в систему вы увидите запрос UAC от xbootmgr, разрешите утилите продолжить работу. Через две минуты вы увидите примерно такое окно.
Когда оно исчезнет, в папке C:\Trace должно быть три файла, как показано на рисунке ниже.
Если вы вместо файла boot_BASE+CSWITCH+DRIVERS+POWER_1.etl видите там два других файла с расширением ETL, это может означать, что утилита еще работает, над их объединением в один – подождите несколько минут. При отсутствии изменений выполните в командной строке
и перезагрузите систему. После чего попробуйте заново запустить сбор данных.
Примечание. Если в результате сбоя у вас продолжают записываться отчеты после каждой перезагрузки, выполните:
Анализируемые файлы и первый взгляд на этапы загрузки
Для анализа используются два файла: ETL и создаваемый из него XML.
Я думаю, что вы уже успели дважды щелкнуть файл boot_BASE+CSWITCH+DRIVERS+POWER_1.etl и полюбоваться красивыми графиками и диаграммами. В левой панели графики можно отображать и скрывать, а также переходить к ним двойным щелчком мыши.
В WPA из ADK для Windows 10 сводку этапов загрузки можно получить так. Из меню Profiles — Apply — Browse Catalog выберите FullBoot.Boot.wpaprofile. При этом автоматически открывается несколько вкладок с подборками сведений. Для отображения информации на отдельной вкладке из левой панели выберите Regions of interest — FullBoot. Получите такую диаграмму и таблицу.
График Boot Phases отражает длительность основных этапов загрузки, которые мы будем рассматривать подробнее дальше. На нем видно, что последний этап, Post Boot занял 26 секунд (Duration), а общее время загрузки составило 64 секунды (End Time).
Для определения длительности основных этапов загрузки можно выделять их мышью, как показано в нижней части рисунка. Можно также щелкнуть на графике правой кнопкой мыши и выбрать из меню пункт Summary Table, чтобы получить отчет в табличном режиме (верхняя часть рисунка).
Для удаленной диагностики по почте или в форуме можно создать текстовый отчет в виде XML-файла. Выполните команды:
Первая переходит в папку с логами, а вторая — создает требуемый XML-файл. Для его просмотра отлично подойдет Internet Explorer!
Сложите узлы, как показано на рисунке, чтобы лучше видеть общую картину. В узле timing указано время в миллисекундах, и там можно увидеть длительность двух больших, условно говоря, частей загрузки (выделены зеленым):
Время первой части складывается из основных этапов загрузки операционной системы (обведены синим), вплоть до начала загрузки рабочего стола. В уже знакомом вам событии 100 журнала Diagnostics-Performance длительность этого этапа записывается в параметре MainPathBootTime.
Разница между этими двумя частями – это время от начала загрузки рабочего стола, до его полной готовности. В событии 100 журнала Diagnostics-Performance — это BootPostBootTime.
Этапы загрузки Windows и их диагностика
Для анализа загрузки нужно представлять, не только в какой последовательности эти этапы идут, но и что происходит на каждом из них. К сожалению, официальная документация по этому вопросу существует только на английском и достаточно сложна технически. Далее я предлагаю вам выдержки из этого документа в своем изложении, с дополнениями и в сопровождении собственных примеров диагностики.
На рисунке ниже представлены три основных этапа загрузки, причем главный из них состоит из четырех фаз.
Давайте рассмотрим все этапы подробно.
Этап OSLoader
Этап OSLoader следует сразу после инициализации BIOS. Визуально он начинается после заставки и диагностических экранов BIOS, а заканчивается примерно с появлением экрана «Загрузка Windows».
Длительность этапа отражает значение параметра osLoaderDuration в узле timing XML-файла. Обычно, она в находится в пределах 2-3 секунд.
Этап MainPathBoot
Визуально этап MainPathBoot начинается с экрана «Загрузка Windows» и завершается при появлении рабочего стола. Если не настроен автоматический вход в систему, длительность этого этапа увеличивается за счет времени, которое требуется для ввода пароля.
Во время этапа MainPathBoot происходит основная работа по загрузке операционной системы:
Этап состоит из четырех фаз, каждая из которых обладает собственными характеристиками и может по-своему влиять на длительность загрузки системы.
Фаза PreSMSS
Визуально фаза PreSMSS начинается примерно с экрана «Загрузка Windows», но ее окончание невозможно определить на глаз.
Фаза PreSMSS (в графическом представлении WPT она обозначена как Pre Session Init) начинается с инициализации ядра. Во время нее:
Если фаза занимает много времени, ищите в XML-файле в узле
драйвер, который долго загружается. Диагностику в графическом режиме я покажу на примере следующей фазы.
Фаза SMSSInit
Визуально начало фазы SMSSInit невозможно определить. Ее частью является пустой экран, который отображается между заставкой и экраном входа в систему, чье появление сигнализирует о завершении фазы.
Фаза SMSSInit (в графическом представлении WPT она обозначена как Session Init) начинается с того, что ядро передает контроль диспетчеру сессий (smss.exe). Во время этой фазы система:
Фаза завершается с передачей контроля процессу winlogon.exe.
Наиболее распространенной причиной задержек в этой фазе являются драйвер видеокарты. Он инициализируется сначала во время системной сессии, а затем во время пользовательской. При этом инициализация во время пользовательской сессии занимает меньше времени, потому что в течение системной параллельно выполняется запуск других задач.
Сократив время запуска драйвера видеокарты, можно уменьшить длительность загрузки системы. Таким образом, если фаза SMSSInit затягивается, обновите драйвер видеокарты.
Более точную диагностику можно провести с помощью summary_boot.xml, где в узле PNP есть длительность запуска каждого драйвера. Впрочем, в Windows 10 он иногда отсутствует, и я не знаю, от чего это зависит и как это форсировать.
⚠ Показанного ниже графика Driver Delays в WPT больше нет, но во времена Windows 7 его можно было анализировать примерно так:
Вы увидите все драйверы, загружавшиеся в фазе Session Init дольше заданного времени. У меня вся фаза занимает 6 секунд, и двухсекундная задержка драйверов является нормальной. Но если у вас проблемы в этой фазе, с помощью фильтра вы сразу увидите, какой драйвер их вызывает.
Фаза WinLogonInit
Визуально фаза WinLogonInit начинается перед появлением экрана приветствия, а завершается перед появлением рабочего стола.
Фаза WinLogonInit начинается сразу после запуска winlogon.exe. Во время этой фазы:
Фаза завершается запуском оболочки Windows — процесса explorer.exe.
Во время фазы WinLogonInit выполняется множество параллельных операций. На многих системах она характеризуется нагрузкой на процессор и большим количеством операций ввода-вывода (I/O). Длительность фазы во многом зависит от поведения служб.
Чтобы обеспечить плавную загрузку системы, службы могут объявлять зависимости или использовать порядковые группы загрузки. Windows обрабатывает группы загрузки в последовательном порядке. Поэтому задержка даже одной службы в ранней группе может затягивать загрузку следующей группы служб и тормозить весь процесс загрузки.
Для выявления проблемной службы удобнее всего использовать графические возможности WPT. Откройте ETL-файл двойным щелчком мыши и прокрутите отчеты вниз до графика запуска служб.
Зачастую проблема вызвана не системными, а сторонними службами. На рисунке хорошо видно, что среди автоматически стартующих служб дольше всего загружаются три:
При этом Apache блокирует загрузку следующей группы служб (очевидно, в ее отсутствие это сделала бы служба TeamViewer). Поскольку ни одна из этих служб не является системной, проблему легко решить. Можно в оснастке «Службы» изменить тип ее запуска на отложенный и посмотреть, будет ли она быстрее запускаться на более позднем этапе. Если это не дает эффекта, можно вовсе отключить службу и запускать ее вручную при необходимости. Во второй волне служб, имеющих отложенный тип запуска, видна задержка WSearch, отвечающей за поиск Windows, но я не стал ее трогать пока.
Чтобы увидеть время запуска каждой службы, щелкните точку начала запуска и растяните диапазон до ее конца. Для изменения масштаба графика крутите колесо мыши, удерживая нажатой клавишу CTRL.
Отключение трех вышеперечисленных служб позволило сократить общее время загрузки почти на 40 секунд! Обратите внимание, что группа автоматического запуска служб теперь стартовала намного быстрее (смотреть нужно относительно шкалы времени, т.к. масштаб графиков разный).
Wsearch все равно запускается дольше других служб, но уже всего 8 секунд вместо 30, что не дает мне достаточно оснований к ней придираться.
Если задержку вызывает антивирусная программа, отложенный запуск службы может понизить уровень защиты, а ручной запуск или отключение службы могут нарушить работу программы. В этом случае можно лишь посоветовать обновить антивирус до последней версии. Если это не дает эффекта, вам придется сделать выбор между любимой программой и длительностью загрузки.
Фаза ExplorerInit
Визуально фаза ExplorerInit начинается перед загрузкой рабочего стола, но ее окончание определить на глаз невозможно.
В фазе ExplorerInit:
Инциализация DWM и рабочего стола происходит на переднем плане, но в это же время в фоне диспетчер управления службами (SCM) запускает службы, а диспетчер памяти кеширует данные. Поэтому на многих системах эта фаза сопровождается нагрузкой на процессор, и нередко задержки при загрузке на этом этапе можно отнести на счет слабости аппаратных ресурсов.
В течение фазы ExplorerInit ресурсы процессора могут потреблять программы, работающие в качестве служб (например, защитные программы или серверы приложений). Они запускаются либо в этой фазе, либо продолжают свою загрузку, будучи запущенными в более ранних фазах. С другой стороны, некоторые службы (например, с отложенным запуском) могут быть еще не запущены на момент окончания фазы ExplorerInit.
Этап PostBoot
Этап PostBoot начинается после появления рабочего стола и завершается после того, как будет определено бездействие системы.
На этапе PostBoot рабочий стол уже загружен, и с ним можно взаимодействовать. Но при этом параллельно в фоне выполняется различная активность. Например, продолжается запуск служб и программ автозагрузки, что может сопровождаться появлением их значков в области уведомлений.
Средства WPT определяют бездействие системы по следующему алгоритму. Каждые 100 мс проверяется наличие активности в системе. Если бездействие системы составляет не менее 80% (за исключением низкоприоритетных процессов и дисковой активности), считается, что в этом интервале система бездействует. Проверка продолжается до тех пор, пока не наберется 10 секунд бездействия. Поэтому, определяя общее время загрузки системы, вычитайте из значения bootDoneViaPostBoot 10000 мс, т.е. 10 секунд.
На этапе PostBoot запускаются приложения, находящиеся в автозагрузке. Чтобы сократить длительность этого этапа, нужно навести там порядок. В графическом представлении WPT используйте график Process Lifetimes, чтобы увидеть все процессы, которые запускаются или продолжают запуск на данном этапе.
Безусловно, диагностика загрузки с помощью WPT требует навыка, и с наскоку разобраться в этом вопросе непросто. Но от вас и не требуется профессиональных знаний, поскольку текстовый отчет в XML файле вкупе с полным графическим представлением всех этапов загрузки позволяет быстро определить причину задержек при запуске Windows. Мне будет очень интересно узнать, полезна ли эта статья, помогла ли она выявить и устранить задержки с помощью WPT, а также насколько ускорилась загрузка системы в результате.
Об авторе
ETW Event Tracing for Windows and ETL Files
Looking for a «new» Windows artifact that is currently being under-utilized and contains a wealth of information? Event Tracing for Windows (ETW) and Event Trace Logs (ETL) may be your answer.
ETW (Event Tracing for Windows)
Triggered Events vs. Triggered Snapshots
Event Tracing is mainly used by Windows and application developers. For example, Windows uses ETW for tracing the shutdown and boot processes and application developers use ETW to debug their applications.
Some examples include:
ETL files stored to disk vary in their volatility and the data they contain. When a trace session is first configured, the settings used determine how log files are to be stored and what data is to be stored in them. Some logs are circular with old data being overwritten with new data when the max file size is reached, others have triggers that result in the contents of the log file being obliterated and starting fresh, and others have multiple log files for each instance that the event trace session flushed events to disk.
Windows stores information into ETL files when the system is shutdown, booted, a second user has logged into the system, when performing updates and more.
Microsoft Lync, Office, OneDrive, SkyDrive and Skype can also maintain their own ETL files containing debugging and other information.
ETL File Locations
ETL files can be found practically anywhere on a Windows system. Some ETL files worth noting are listed below. These files have been observed as existing on most systems and can contain a great deal of information ripe for analysis. Some of these files will be explained in more detail later.
A link to a list of additional observed file locations can be found below. Note that this list is not all inclusive and there may be more locations not documented here.
Also, the existence of these ETLs on a system depends on many factors. Therefore, some of these files might not exist on the system you are analyzing. In research, some of the files were empty and others contained copious amounts of data.
ETL Files
Decoding ETL Files
There are several Microsoft tools available for viewing/parsing ETL log files.
— Windows Event Viewer
— Microsoft Message Analyzer
— TraceView
— TraceFmt
— SvcTraceView
— Netmon
— PerfView
Windows Event Viewer is not only for EVTs and EVTXs, it can also read an ETL file. After opening an ETL in Event Viewer, you can save the ETL in various formats including as a CSV file.
However, depending on the type of ETL file, Event Viewer may not decode the event payload data and may not report event specific fields.
Microsoft Message Analyzer does a better job at decoding event data.
If you wish to write your own tool in C# you can tap into the NuGet TraceEvent library to read events from an ETL file.
Decoding Issues
It is important to note that when decoding an ETL on a system that is not the source system, information needed to properly decode event data might not be available.
When an event provider is registered on a system, it also registers information needed to decode the event data. If the event provider is not registered on the system you are using to decode an ETL file, the tool will not be able to properly parse the events.
Also, some ETL files require a separate PDB (program debugging database) to decode events. Microsoft Message Analyzer has an option that allows PDBs to be downloaded and used to decode ETL files. However, some ETL files require private PDBs that are not available for download.
ETL File Volatility
As previously mentioned, trace events are not always written to disk. When an event trace session is configured, how the data is logged is also configured. https://msdn.microsoft.com/en-us/library/windows/desktop/aa364080(v=vs.85).aspx
Event trace sessions that are configured to be circular will overwrite old events with new events when the max file/buffer size is reached. The old events that were overwritten are not recoverable. The WiFi.etl, BootCKCL.etl and ShutdownCKCL.etl files are examples of circular log files in testing.
Other event trace sessions can pre-allocate disk space and write events to disk when triggered. For example, Outlook when debug settings have been configured will write events to a log file when Outlook is closed.
ETW and Live Monitoring
While this discussion focuses on offline forensics, there are numerous uses for ETW live monitoring.
In one example, a security research company published a proof of concept related to Logging Keystrokes with ETW.
Interesting Logs and Events
ShutdownCKCL and BootCKCL ETL Files
The ShutdownCKCL and BootCKCL are circular kernel context logs (CKCL) which contain information about the system that the event trace session knows at the time it was either shutdown or booted.
These log files are located in “%SystemRoot% \Windows\System32\WDI\LogFiles”.
Изучаем 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-провайдерами и сессиями. Контроллеры могут запрашивать состояние активных в данный момент сессий и получать списки всех зарегистрированных в системе провайдеров. Например, для получения всех активных сессий следует использовать следующую команду:
а для получения списка всех зарегистрированных в системе провайдеров — команду:
Контроллеры обладают еще несколькими ключевыми функциями. Они могут обновлять сессии и сбрасывать содержимое буферов на диск.
К сожалению, в данной статье я не затронул некоторое количество интересных вопросов (например, потребление событий в режиме реального времени или работу с сессиями специального назначения).
Об этом можно почитать на следующих сайтах: