Kernel eventtracing что это

6

Изучаем Event Tracing for Windows: теория и практика

Добрый день. Недавно мне необходимо было разобраться со службой трассировки Windows. Эта служба появилась еще в Windows 2000, однако статей по этой службе в интернете оказалось крайне мало.Так появилась идея написания этой статьи. Итак, начнем!

Сегодня я попытаюсь рассказать про:

1. Теоретические основы службы трассировки Windows
2. Создание своей сессии ETW
3. Использование event tracing API для работы с ETW
4. Использование tracerpt и xperf для работы с ETW

Теоретические основы службы трассировки Windows

Event Tracing for Windows (ETW) — это служба, которая позволяет получать события от одного или нескольких поставщиков событий в режиме реального времени или из файла *.etl за некоторый временной период. Не понятно? Сейчас разберемся!

Для того, чтобы понять принцип работы ETW, необходимо разобраться со структурой этой службы

Архитектура ETW включает в себя 4 элемента

1. поставщики событий (providers)
2. потребители событий (consumers)
3. контроллеры ETW (controllers)
4. сессии ETW (event tracing sessions)

В системе зарегистрировано некоторое число поставщиков событий, т.е. приложений, которые могут делиться своими событиями с сессиями ETW. Так же в этой системе есть некоторое число активных сессий ETW, которые могут потреблять события от одного или нескольких поставщиков и предоставлять их пользователю либо в режиме реального времени, либо записывать все события от поставщиков в файл логирования (*.etl). И управляют всем этим движением контроллеры.

А теперь рассмотрим каждый элемент рассмотренной выше архитектуры подробнее, чтобы окончательно разобраться с принципом работы!

Поставщики событий (providers)

Поставщики событий — это приложения, содержащие инструменты отслеживания событий. После того, как поставщик зарегистрировался, контроллер может включить или отключить отслеживание событий в поставщике. Поставщик определяет свою интерпретацию включения или выключения. Как правило, включенный поставщик генерирует события, а отключенный поставщик нет. Это позволяет добавлять отслеживание событий в наше приложение, не требуя, чтобы оно генерировало события все время.

Один поставщик может делиться своими событиями сразу с несколькими сессиями ETW.

Каждое событие состоит из двух элементов: заголовка и данных! Заголовок события включает информацию о событии: идентификатор провайдера, идентификатор события, временную метку и т.д. Остальные данные определяются конкретным провайдером: ETW принимает любые данные и записывает их в буфер, а их интерпретация возлагается на потребителей информации.
Существует четыре основных типа провайдеров:

поставщики MOF (классические)
провайдеры WPP
провайдеры на основе манифеста
провайдеры TraceLogging.

Поставщики событий различаются по типам полей, которые они хранят в полезных нагрузках событий.

С поставщиками событий вроде разобрались. Идем дальше!

Контроллеры

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

Потребители

Потребители — это приложения, которые получают и обрабатывают события от одного или нескольких сеансов трассировки одновременно. Потребители могут получать события, хранящиеся в файлах журналов или из сеансов, которые доставляют события в режиме реального времени. Как мы уже знаем, у одной сессии ETW может быть несколько поставщиков. Возникает вопрос: а не будет ли путаницы? Как события из различных сессий ETW будут располагаться друг относительно друга? События сортируются по времени их появления, т.е. система доставляет события в хронологическом порядке!

Сессии ETW

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

Трассировка событий поддерживает до 64 сеансов трассировки событий, выполняющихся одновременно. Из этих сессий есть две сессии специального назначения. Остальные сеансы доступны для общего пользования. Две сессии специального назначения:

• Global Logger Session
• NT Kernel Logger Session

Итак, а теперь переходим к практике.

Создание своей сессии ETW

Перед началом работы нам потребуется знание нескольких утилит, а именно:

список провайдеров, доступных на конкретной ОС

получить полную информацию о провайдере

список всех активный сессий ETW

Так же, для просмотра файлов, желательно иметь Notepad++.

Просмотрев список провайдеров на своем компьютере (а их более 1000 на Windows 10), выберем один из них для нашей сессии:

Я выбрал Microsoft-Windows-WinINet (эта служба записывает все наши действия при работе в браузере Microsoft Edge).

1. Win+R -> compmgmt.msc
2. «Performance» («Производительность»)
3. «Data Collector Sets» («Группы сборщиков данных»)
4. «Event Trace Sessions» («Сеансы отслеживания событий»)
5. «New» («Создать»)
6. «Data Collector Set» («Группа сборщиков данных)
7. Указываем имя сборщика данных
8. „Create manually (Advanced)“ (»Создать вручную (для опытных)»)

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

В этой статье Вы найдете ответы на многие вопросы, которые у вас скорее всего возникнут при написании приложений!

Кодить будем на C++.

Начнем с самого простого.

Настройка и запуск сеанса отслеживания событий

Для начала рассмотрим общую идею.

Чтобы запустить сеанс трассировки необходимо:

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-провайдерами и сессиями. Контроллеры могут запрашивать состояние активных в данный момент сессий и получать списки всех зарегистрированных в системе провайдеров. Например, для получения всех активных сессий следует использовать следующую команду:

а для получения списка всех зарегистрированных в системе провайдеров — команду:

Контроллеры обладают еще несколькими ключевыми функциями. Они могут обновлять сессии и сбрасывать содержимое буферов на диск.

На этом пока все!

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

Как исправить Microsoft-Windows-Kernel-EventTracing%4Admin.evtx (бесплатная загрузка)

Файлы Windows 7 Event Log, такие как Microsoft-Windows-Kernel-EventTracing%4Admin.evtx, считаются разновидностью файла Система (Windows 7 Event Log). Они соотносятся с расширением EVTX, разработанным компанией eyeClaxton Software для Find Junk Files 1.51 build 1318.

Первая версия Microsoft-Windows-Kernel-EventTracing%4Admin.evtx для WindowBlinds 10.62 увидела свет 05/09/2017 в Windows 10. Последним обновлением версии [v1.51 build 1318] для Find Junk Files является 1.51 build 1318, выпущенное 07/10/2011. Файл Microsoft-Windows-Kernel-EventTracing%4Admin.evtx включен в Find Junk Files 1.51 build 1318, BullGuard Internet Security 2013 и Registry Repair Wizard 2012 6.72.

В этой статье приведены подробные сведения о Microsoft-Windows-Kernel-EventTracing%4Admin.evtx, руководство по устранению неполадок с файлом EVTX и список версий, доступных для бесплатной загрузки.

Рекомендуемая загрузка: исправить ошибки реестра в WinThruster, связанные с Microsoft-Windows-Kernel-EventTracing%4Admin.evtx и (или) Find Junk Files.

Совместимость с Windows 10, 8, 7, Vista, XP и 2000

Средняя оценка пользователей

Обзор файла

✻ Фрагменты данных файлов предоставлены участником Exiftool (Phil Harvey) и распространяются под лицензией Perl Artistic.

Что такое сообщения об ошибках Microsoft-Windows-Kernel-EventTracing%4Admin.evtx?

Общие ошибки выполнения Microsoft-Windows-Kernel-EventTracing%4Admin.evtx

Ошибки файла Microsoft-Windows-Kernel-EventTracing%4Admin.evtx часто возникают на этапе запуска Find Junk Files, но также могут возникать во время работы программы. Эти типы ошибок EVTX также известны как «ошибки выполнения», поскольку они возникают во время выполнения Find Junk Files. К числу наиболее распространенных ошибок выполнения Microsoft-Windows-Kernel-EventTracing%4Admin.evtx относятся:

• Не удается найти Microsoft-Windows-Kernel-EventTracing%4Admin.evtx.
• Microsoft-Windows-Kernel-EventTracing%4Admin.evtx — ошибка.
• Не удалось загрузить Microsoft-Windows-Kernel-EventTracing%4Admin.evtx.
• Ошибка при загрузке Microsoft-Windows-Kernel-EventTracing%4Admin.evtx.
• Не удалось зарегистрировать Microsoft-Windows-Kernel-EventTracing%4Admin.evtx / Не удается зарегистрировать Microsoft-Windows-Kernel-EventTracing%4Admin.evtx.
• Ошибка выполнения — Microsoft-Windows-Kernel-EventTracing%4Admin.evtx.
• Файл Microsoft-Windows-Kernel-EventTracing%4Admin.evtx отсутствует или поврежден.

Программа: C:\Windows\System32\winevt\Logs\Microsoft-Windows-Kernel-EventTracing%4Admin.evtx

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

В большинстве случаев причинами ошибок в EVTX являются отсутствующие или поврежденные файлы. Файл Microsoft-Windows-Kernel-EventTracing%4Admin.evtx может отсутствовать из-за случайного удаления, быть удаленным другой программой как общий файл (общий с Find Junk Files) или быть удаленным в результате заражения вредоносным программным обеспечением. Кроме того, повреждение файла Microsoft-Windows-Kernel-EventTracing%4Admin.evtx может быть вызвано отключением питания при загрузке Find Junk Files, сбоем системы при загрузке или сохранении Microsoft-Windows-Kernel-EventTracing%4Admin.evtx, наличием плохих секторов на запоминающем устройстве (обычно это основной жесткий диск) или заражением вредоносным программным обеспечением. Таким образом, крайне важно, чтобы антивирус постоянно поддерживался в актуальном состоянии и регулярно проводил сканирование системы.

Как исправить ошибки Microsoft-Windows-Kernel-EventTracing%4Admin.evtx — 3-шаговое руководство (время выполнения:

Если вы столкнулись с одним из вышеуказанных сообщений об ошибке, выполните следующие действия по устранению неполадок, чтобы решить проблему Microsoft-Windows-Kernel-EventTracing%4Admin.evtx. Эти шаги по устранению неполадок перечислены в рекомендуемом порядке выполнения.

Шаг 1. Восстановите компьютер до последней точки восстановления, «моментального снимка» или образа резервной копии, которые предшествуют появлению ошибки.

Чтобы начать восстановление системы (Windows XP, Vista, 7, 8 и 10):

1. Нажмите кнопку «Пуск» в Windows
2. В поле поиска введите «Восстановление системы» и нажмите ENTER.
3. В результатах поиска найдите и нажмите «Восстановление системы»
4. Введите пароль администратора (при необходимости).
5. Следуйте инструкциям мастера восстановления системы, чтобы выбрать соответствующую точку восстановления.
6. Восстановите компьютер к этому образу резервной копии.

Если на этапе 1 не удается устранить ошибку Microsoft-Windows-Kernel-EventTracing%4Admin.evtx, перейдите к шагу 2 ниже.

Шаг 2. Если вы недавно установили приложение Find Junk Files (или схожее программное обеспечение), удалите его, затем попробуйте переустановить Find Junk Files.

Чтобы удалить программное обеспечение Find Junk Files, выполните следующие инструкции (Windows XP, Vista, 7, 8 и 10):

1. Нажмите кнопку «Пуск» в Windows
2. В поле поиска введите «Удалить» и нажмите ENTER.
3. В результатах поиска найдите и нажмите «Установка и удаление программ»
4. Найдите запись для Find Junk Files 1.51 build 1318 и нажмите «Удалить»
5. Следуйте указаниям по удалению.

После полного удаления приложения следует перезагрузить ПК и заново установить Find Junk Files.

Если на этапе 2 также не удается устранить ошибку Microsoft-Windows-Kernel-EventTracing%4Admin.evtx, перейдите к шагу 3 ниже.

Find Junk Files 1.51 build 1318

Шаг 3. Выполните обновление Windows.

Когда первые два шага не устранили проблему, целесообразно запустить Центр обновления Windows. Во многих случаях возникновение сообщений об ошибках Microsoft-Windows-Kernel-EventTracing%4Admin.evtx может быть вызвано устаревшей операционной системой Windows. Чтобы запустить Центр обновления Windows, выполните следующие простые шаги:

1. Нажмите кнопку «Пуск» в Windows
2. В поле поиска введите «Обновить» и нажмите ENTER.
3. В диалоговом окне Центра обновления Windows нажмите «Проверить наличие обновлений» (или аналогичную кнопку в зависимости от версии Windows)
4. Если обновления доступны для загрузки, нажмите «Установить обновления».
5. После завершения обновления следует перезагрузить ПК.

Если Центр обновления Windows не смог устранить сообщение об ошибке Microsoft-Windows-Kernel-EventTracing%4Admin.evtx, перейдите к следующему шагу. Обратите внимание, что этот последний шаг рекомендуется только для продвинутых пользователей ПК.

Если эти шаги не принесут результата: скачайте и замените файл Microsoft-Windows-Kernel-EventTracing%4Admin.evtx (внимание: для опытных пользователей)

Если ни один из предыдущих трех шагов по устранению неполадок не разрешил проблему, можно попробовать более агрессивный подход (примечание: не рекомендуется пользователям ПК начального уровня), загрузив и заменив соответствующую версию файла Microsoft-Windows-Kernel-EventTracing%4Admin.evtx. Мы храним полную базу данных файлов Microsoft-Windows-Kernel-EventTracing%4Admin.evtx со 100%-ной гарантией отсутствия вредоносного программного обеспечения для любой применимой версии Find Junk Files . Чтобы загрузить и правильно заменить файл, выполните следующие действия:

1. Найдите версию операционной системы Windows в нижеприведенном списке «Загрузить файлы Microsoft-Windows-Kernel-EventTracing%4Admin.evtx».
2. Нажмите соответствующую кнопку «Скачать», чтобы скачать версию файла Windows.
3. Скопируйте этот файл в соответствующее расположение папки Find Junk Files:

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

Kernel-EventTracing код события 2 — как исправить?

Он начался с 28.11.2019 по сегодняшний день, о чем свидетельствуют события. Все ошибки копировать не буду, все в файле.

Что это за ошибки и как их исправить?

event file.evtx — это файл события.

До свидания!
Эта ошибка никак не влияет на работу, это просто запись в журнале событий)
Сам факт появления этого слуха — это «баг» в операционной системе)
Сообщите об этом разработчикам ОС с помощью приложения Feedback Center, встроенного в ОС.
Саму ошибку можно проигнорировать)

Спасибо за понимание! __
Если мой ответ был вам полезен, отметьте его как ответ.

Отказ от ответственности: ответ может содержать ссылки на сайты, отличные от сайтов Microsoft. Вы следуете любым советам таких сайтов на свой страх и риск.

Event Tracing¶

Tracepoints (see Using the Linux Kernel Tracepoints ) can be used without creating custom kernel modules to register probe functions using the event tracing infrastructure.

Not all tracepoints can be traced using the event tracing system; the kernel developer must provide code snippets which define how the tracing information is saved into the tracing buffer, and how the tracing information should be printed.

2. Using Event Tracing¶

2.1 Via the ‘set_event’ interface¶

The events which are available for tracing can be found in the file /sys/kernel/tracing/available_events.

To enable a particular event, such as ‘sched_wakeup’, simply echo it to /sys/kernel/tracing/set_event. For example:

‘>>’ is necessary, otherwise it will firstly disable all the events.

To disable an event, echo the event name to the set_event file prefixed with an exclamation point:

To disable all events, echo an empty line to the set_event file:

To enable all events, echo *:* or *: to the set_event file:

The events are organized into subsystems, such as ext4, irq, sched, etc., and a full event name looks like this: <subsystem>:<event>. The subsystem name is optional, but it is displayed in the available_events file. All of the events in a subsystem can be specified via the syntax <subsystem>:* ; for example, to enable all irq events, you can use the command:

2.2 Via the ‘enable’ toggle¶

The events available are also listed in /sys/kernel/tracing/events/ hierarchy of directories.

To enable event ‘sched_wakeup’:

To enable all events in sched subsystem:

To enable all events:

When reading one of these enable files, there are four results:

• 0 — all events this file affects are disabled

• 1 — all events this file affects are enabled

• X — there is a mixture of events enabled and disabled

• ? — this file does not affect any event

2.3 Boot option¶

In order to facilitate early boot debugging, use boot option:

event-list is a comma separated list of events. See section 2.1 for event format.

3. Defining an event-enabled tracepoint¶

See The example provided in samples/trace_events

4. Event formats¶

Each trace event has a ‘format’ file associated with it that contains a description of each field in a logged event. This information can be used to parse the binary trace stream, and is also the place to find the field names that can be used in event filters (see section 5).

It also displays the format string that will be used to print the event in text mode, along with the event name and ID used for profiling.

Every event has a set of common fields associated with it; these are the fields prefixed with common_ . The other fields vary between events and correspond to the fields defined in the TRACE_EVENT definition for that event.

Each field in the format has the form:

where offset is the offset of the field in the trace record and size is the size of the data item, in bytes.

For example, here’s the information displayed for the ‘sched_wakeup’ event:

This event contains 10 fields, the first 5 common and the remaining 5 event-specific. All the fields for this event are numeric, except for ‘comm’ which is a string, a distinction important for event filtering.

5. Event filtering¶

Trace events can be filtered in the kernel by associating boolean ‘filter expressions’ with them. As soon as an event is logged into the trace buffer, its fields are checked against the filter expression associated with that event type. An event with field values that ‘match’ the filter will appear in the trace output, and an event whose values don’t match will be discarded. An event with no filter associated with it matches everything, and is the default when no filter has been set for an event.

5.1 Expression syntax¶

A filter expression consists of one or more ‘predicates’ that can be combined using the logical operators ‘&&’ and ‘||’. A predicate is simply a clause that compares the value of a field contained within a logged event with a constant value and returns either 0 or 1 depending on whether the field value matched (1) or didn’t match (0):

Parentheses can be used to provide arbitrary logical groupings and double-quotes can be used to prevent the shell from interpreting operators as shell metacharacters.

The field-names available for use in filters can be found in the ‘format’ files for trace events (see section 4).

The relational-operators depend on the type of the field being tested:

The operators available for numeric fields are:

And for string fields they are:

) accepts a wild card character (*,?) and character classes ([). For example:

If the field is a pointer that points into user space (for example “filename” from sys_enter_openat), then you have to append “.ustring” to the field name:

As the kernel will have to know how to retrieve the memory that the pointer is at from user space.

You can convert any long type to a function address and search by function name:

The above will filter when the field “call_site” falls on the address within “security_prepare_creds”. That is, it will compare the value of “call_site” and the filter will return true if it is greater than or equal to the start of the function “security_prepare_creds” and less than the end of that function.

The “.function” postfix can only be attached to values of size long, and can only be compared with “==” or “!=”.

5.2 Setting filters¶

A filter for an individual event is set by writing a filter expression to the ‘filter’ file for the given event.

A slightly more involved example:

If there is an error in the expression, you’ll get an ‘Invalid argument’ error when setting it, and the erroneous string along with an error message can be seen by looking at the filter e.g.:

Currently the caret (‘^’) for an error always appears at the beginning of the filter string; the error message should still be useful though even without more accurate position info.

5.2.1 Filter limitations¶

If a filter is placed on a string pointer (char *) that does not point to a string on the ring buffer, but instead points to kernel or user space memory, then, for safety reasons, at most 1024 bytes of the content is copied onto a temporary buffer to do the compare. If the copy of the memory faults (the pointer points to memory that should not be accessed), then the string compare will be treated as not matching.

5.3 Clearing filters¶

To clear the filter for an event, write a ‘0’ to the event’s filter file.

To clear the filters for all events in a subsystem, write a ‘0’ to the subsystem’s filter file.

5.4 Subsystem filters¶

For convenience, filters for every event in a subsystem can be set or cleared as a group by writing a filter expression into the filter file at the root of the subsystem. Note however, that if a filter for any event within the subsystem lacks a field specified in the subsystem filter, or if the filter can’t be applied for any other reason, the filter for that event will retain its previous setting. This can result in an unintended mixture of filters which could lead to confusing (to the user who might think different filters are in effect) trace output. Only filters that reference just the common fields can be guaranteed to propagate successfully to all events.

Here are a few subsystem filter examples that also illustrate the above points:

Clear the filters on all events in the sched subsystem:

Set a filter using only common fields for all events in the sched subsystem (all events end up with the same filter):

Attempt to set a filter using a non-common field for all events in the sched subsystem (all events but those that have a prev_pid field retain their old filters):

5.5 PID filtering¶

The set_event_pid file in the same directory as the top events directory exists, will filter all events from tracing any task that does not have the PID listed in the set_event_pid file.

Will only trace events for the current task.

To add more PIDs without losing the PIDs already included, use ‘>>’.

6. Event triggers¶

Trace events can be made to conditionally invoke trigger ‘commands’ which can take various forms and are described in detail below; examples would be enabling or disabling other trace events or invoking a stack trace whenever the trace event is hit. Whenever a trace event with attached triggers is invoked, the set of trigger commands associated with that event is invoked. Any given trigger can additionally have an event filter of the same form as described in section 5 (Event filtering) associated with it — the command will only be invoked if the event being invoked passes the associated filter. If no filter is associated with the trigger, it always passes.

Triggers are added to and removed from a particular event by writing trigger expressions to the ‘trigger’ file for the given event.

A given event can have any number of triggers associated with it, subject to any restrictions that individual commands may have in that regard.

Event triggers are implemented on top of “soft” mode, which means that whenever a trace event has one or more triggers associated with it, the event is activated even if it isn’t actually enabled, but is disabled in a “soft” mode. That is, the tracepoint will be called, but just will not be traced, unless of course it’s actually enabled. This scheme allows triggers to be invoked even for events that aren’t enabled, and also allows the current event filter implementation to be used for conditionally invoking triggers.

The syntax for event triggers is roughly based on the syntax for set_ftrace_filter ‘ftrace filter commands’ (see the ‘Filter commands’ section of ftrace — Function Tracer ), but there are major differences and the implementation isn’t currently tied to it in any way, so beware about making generalizations between the two.

Writing into trace_marker (See ftrace — Function Tracer ) can also enable triggers that are written into /sys/kernel/tracing/events/ftrace/print/trigger

6.1 Expression syntax¶

Triggers are added by echoing the command to the ‘trigger’ file:

Triggers are removed by echoing the same command but starting with ‘!’ to the ‘trigger’ file:

The [if filter] part isn’t used in matching commands when removing, so leaving that off in a ‘!’ command will accomplish the same thing as having it in.

The filter syntax is the same as that described in the ‘Event filtering’ section above.

For ease of use, writing to the trigger file using ‘>’ currently just adds or removes a single trigger and there’s no explicit ‘>>’ support (‘>’ actually behaves like ‘>>’) or truncation support to remove all triggers (you have to use ‘!’ for each one added.)

6.2 Supported trigger commands¶

The following commands are supported:

These commands can enable or disable another trace event whenever the triggering event is hit. When these commands are registered, the other trace event is activated, but disabled in a “soft” mode. That is, the tracepoint will be called, but just will not be traced. The event tracepoint stays in this mode as long as there’s a trigger in effect that can trigger it.

For example, the following trigger causes kmalloc events to be traced when a read system call is entered, and the :1 at the end specifies that this enablement happens only once:

The following trigger causes kmalloc events to stop being traced when a read system call exits. This disablement happens on every read system call exit: