我试图了解如何使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事件。在我的应用程序中，我使用一个跟踪会话来捕获所有内容。我注意到有关用于rundown会话的EVENT_TRACE_PROPERTIES的一个有趣的事情是它没有指定任何EnableFlags。 “主”会话使用我期望的标志（DISK_IO，FILE_IO，NETWORK_TCPIP）。
其次，ProcessHacker使用较新的“EventRecord”回调而不是旧的“EventTrace”回调。我的应用程序正在使用“旧”EventTrace回调。通过在EVENT_TRACE_LOGFILE结构中指定PROCESS_TRACE_MODE_EVENT_RECORD来进行此选择。
这些差异会导致我所看到的行为吗？
答案 0 :(得分：2)
我回答了自己的问题。关键是我指出的第一个区别。我在两个线程之间拆分事件处理任务，而不是尝试处理单个线程中的所有内容。所以，现在我将FileIo，DiskIo和Image事件指向一个线程，将FileCreate，FileRundown和FileName事件指向另一个线程。这解决了这个问题。
这表明我正在沿着链条的某个地方放弃ETW事件。然而，ETW会话统计信息不会报告此事实（EventsLost RealTimeEventsLost和BuffersLost都为零）。
我想这应该是显而易见的，但在尝试处理大量（数百万）ETW事件时，性能至关重要。就我而言，我正在收听Driver级别的事件（DriverCall，DriverComplete等）。这增加了事件的数量，似乎加剧了我所看到的问题。
在解决此问题之前，我运行了一些简单的实验。在实验中，我禁用了驱动程序级事件。在这种情况下，单线程事件处理器能够跟上DiskIo事件和FileName事件。一旦我重新启动Driver事件，我就会回到我无法可靠地接收FileName事件的状态。