Сопоставить объект файла ETW с событиями DiskIO
Я пытаюсь понять, как сделать так, чтобы трассировка ETW работала надежно. Проблема, с которой я сталкиваюсь, заключается в том, что я не получаю последовательно события FileIo или события name, которые мне нужны, чтобы соотнести имена файлов с событиями DiskIo на уровне драйвера. Я использую трассировку событий в реальном времени. Я изучил статистику, возвращаемую из ETW в конце сеанса, и мне кажется, что я не сбрасываю события (EventsLost и RealTimeBuffersLost всегда равны нулю). В некоторых случаях я получаю события FileName / FileRundown, а в других — нет.
Я нашел полезную информацию в этой теме: Как определить имя файла, участвующего в операции ввода-вывода, используя трассировку Windows etw?. Там я нашел несколько ссылок на исходный код для ProcessHacker (http://processhacker.sourceforge.net/doc/etwmon_8c_source.html). Изучая код ProcessHacker, я вижу пару различий в том, как я настраиваю трассировку событий. Интересно, приводят ли эти различия к моим проблемам?
Во-первых, ProcessHacker устанавливает две сессии трассировки. Один получает большую часть желаемых событий ETW (FileIo, DiskIo, NetworkIo). Другой ищет только события FileRundown. В моем приложении я использую один сеанс трассировки, чтобы поймать все. Интересная вещь, которую я замечаю о EVENT_TRACE_PROPERTIES, используемой для сеанса подробного изложения, состоит в том, что он не указывает никаких EnableFlags. «Основной» сеанс использует флаги, которые я ожидал (DISK_IO, FILE_IO, NETWORK_TCPIP).
Во-вторых, ProcessHacker использует более новый обратный вызов «EventRecord» вместо старых обратных вызовов «EventTrace». Мое приложение использует «старый» обратный вызов EventTrace. Этот выбор делается путем указания PROCESS_TRACE_MODE_EVENT_RECORD в структуре EVENT_TRACE_LOGFILE.
Приведет ли любое из этих различий к поведению, которое я наблюдаю?
Решение
Я ответил на свой вопрос. Ключ был первым отличием, которое я указал. Я разделил задачи обработки событий между двумя потоками вместо того, чтобы пытаться обрабатывать все в одном потоке. Итак, теперь я направляю события FileIo, DiskIo и Image в один поток, а события FileCreate, FileRundown и FileName — в другой. Это решило проблему.
Это говорит о том, что я выбрасывал события ETW где-то в цепочке. Тем не менее, статистика сеансов ETW не сообщает об этом факте (EventsLost RealTimeEventsLost и BuffersLost равны нулю).
Я думаю, это должно быть очевидно, но производительность имеет решающее значение при попытке обработать большие объемы (миллионы) событий ETW. В моем случае я слушаю события на уровне драйвера (DriverCall, DriverComplete и т. Д.). Это увеличивает объем событий и, похоже, усугубляет проблему, которую я видел.
Я провел несколько простых экспериментов, прежде чем решить это. В эксперименте я отключил события уровня драйвера. В этом случае однопоточный обработчик событий мог не отставать от событий DiskIo и событий FileName. Как только я снова включаю события драйвера, я возвращаюсь в состояние, когда я не могу получать события FileName.
Другие решения
Других решений пока нет …