将 ETW 文件对象与 DiskIO 事件相关联

Question

我正在尝试了解如何使 ETW 跟踪可靠地工作。我遇到的问题是我没有始终如一地收到我需要的 FileIo 破败或名称事件，以便在驱动程序级别将文件名与 DiskIo 事件相关联。我正在使用实时事件跟踪。我研究了会话结束时从 ETW 返回的统计数据，我似乎没有丢弃事件（EventsLost 和 RealTimeBuffersLost 始终为零）。在某些情况下，我会收到 FileName/FileRundown 事件，而在其他情况下则不会。

我在这个帖子中找到了一些有用的信息：How to determine the file name involved in an IO operation using windows etw tracing?。在那里我找到了一些指向 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 回调。通过在 EVENT_TRACE_LOGFILE 结构中指定 PROCESS_TRACE_MODE_EVENT_RECORD 进行此选择。

这些差异是否会导致我看到的行为？

Answer 1

我回答了我自己的问题。关键是我指出的第一个区别。我在两个线程之间拆分事件处理任务，而不是尝试在单个线程中处理所有内容。所以，现在我将 FileIo、DiskIo 和 Image 事件指向一个线程，将 FileCreate、FileRundown 和 FileName 事件指向另一个线程。这解决了问题。

这表明我在链中的某个地方丢弃了 ETW 事件。然而 ETW 会话统计数据并未报告这一事实（EventsLost RealTimeEventsLost 和 BuffersLost 都为零）。

我想这应该是显而易见的，但在尝试处理大量（数百万）ETW 事件时，性能至关重要。就我而言，我正在监听驱动程序级别的事件（DriverCall、DriverComplete 等）。这增加了事件的数量，似乎加剧了我所看到的问题。

在解决这个问题之前，我进行了一些简单的实验。在实验中，我禁用了 Driver 级别的事件。在这种情况下，单线程事件处理器能够跟上 DiskIo 事件和 FileName 事件。一旦我重新打开驱动程序事件，我就会回到无法可靠接收 FileName 事件的状态。