2

我一直在玩 Windows 事件的事件跟踪，特别是网络事件，NDIS-PacketCapture 和 TCPIP。每个 ETW 消息都有 PID 字段，我试图找出分配背后的逻辑。似乎绝大多数 TCPIP 事件在 PID 字段中具有正确的 PID，并且大多数 NDIS 数据包捕获也是如此。然而，在很多情况下，可能有 30% 的 PID 显然是不正确的。这些不正确的 PID 信息中的一些是假阳性和一些假阴性。例如，它会错过来自 Chrome 的某些数据包，它只会为这种情况分配 PID 0（假阴性）。有时我会获取正在运行的应用程序的 PID，以在 PID 字段中捕获这些事件（误报）。据我分析，

另一个值得注意的有趣的事情是，一些 TCPIP 事件包含一个“PID”属性，该属性有时与标头中的 PID 一致。这个“PID”属性似乎比标头 PID 更准确，但它仍然表现出误报和误报。

我看到错误了吗？我不了解 ETW 消息中 PID 字段的用途吗？这些供应商是否只是选择在他们喜欢的时候放入垃圾？

我在 C++ 中使用 Win32/64 跟踪函数，例如 StartTrace、EnableTraceEx2、OpenTrace 和 ProcessEventRecordProperties(PEVENT_RECORD pEvent) 回调等。更具体地说，我修改了这个示例以提供 NDIS-PacketCapture 和 TCPIP 事件：http://msdn.microsoft.com/en-us/library/windows/desktop/ee441329(v=vs.85).aspx

这是典型 TCPIP 事件的所有值的样子（我使用 xxx.. 作为 IP 和端口号）

------------------Processing Event Record ------------------
Event HEADER (size=136) flags=64bit, type=none
pid=7576 tid=5236 eid=1300
Time: sys=3 usr=2
Event PROVIDER {2f07e2ee-15db-40f1-90ef-9d7ba282188a}
Event ACTIVITY {0ff3b670-fa80-ffff-0000-000000000000}
Provider name: Microsoft-Windows-TCPIP

Provider GUID: {2F07E2EE-15DB-40F1-90EF-9D7BA282188A}
Event message: TCP: connection %1 (local=%3 remote=%5) exists. State = %6. PID = %7. 
Keyword mask: 0x8000080400000084
  Keyword name: ut:TcpipTcb
  Keyword name: ut:TcpipDiagnosis
  Keyword name: ut:ConnectPath
  Keyword name: ut:Endpoint
Event ID: 1300
Tcb: 0xff3b670
LocalAddressLength: 16
LocalAddress:
 xxx.xxx.xxx.xxx:xxxx
RemoteAddressLength: 16
RemoteAddress:
 xxx.xxx.xxx.xxx:xxxx
State: EstablishedState
Pid: 7152

任何帮助是极大的赞赏。

4

0 回答 0