如何让PerfView仅收集单个进程产生的ETW事件

我完全懂你的困扰——收集所有进程的ETW事件生成的*.ETL文件不仅体积大得离谱，还混进一堆无关事件，后续排查起来简直头大。虽然你提到的/Process:NameOrPID参数确实只在/StopXXX这类停止命令里生效，但咱们有其他靠谱办法实现单个进程的ETW事件捕获：

• 用tracelog加进程筛选条件：
  创建跟踪会话时，直接指定目标进程的PID或名称作为筛选规则，就能只捕获该进程的事件。比如要跟踪PID为1234的进程，命令如下：

  tracelog -start MyCustomTrace -f TargetProcess.etl -p "{ProviderGUID}" -filter "ProcessId=1234"
  

  把{ProviderGUID}替换成你要监控的ETW提供者GUID（比如Windows内核提供者GUID是{e13c0d23-ccbc-4e12-931b-d9cc2eee27e4}）。要是想用进程名筛选，把ProcessId=1234改成ProcessName='YourTargetProcess.exe'就行。

• 用logman实现带筛选的跟踪：
  logman也支持进程级筛选，还能设置循环日志避免文件爆增，命令示例：

  logman create trace MyProcessTrace -o TargetProcess.etl -p "{ProviderGUID}" -ets -f bincirc -max 100 -filter "ProcessId=1234"
  

  启动会话用logman start MyProcessTrace -ets，停止用logman stop MyProcessTrace -ets。

• 几个要注意的点：

  • 不是所有ETW提供者都支持进程ID/名称筛选，大部分系统提供者和正规应用提供者都没问题，但少数自定义提供者可能没这个字段，得提前确认。
  • 不知道目标提供者的GUID？用tracelog -l能列出所有已注册的提供者，或者wevtutil gp可以查更详细的信息。

补充一句：之前你碰到/Process参数只对停止命令生效的情况，是因为这个参数本来就是设计用来停止特定进程的跟踪会话，而非限定捕获范围——所以换用上面的筛选条件才是正确的思路。

内容的提问来源于stack exchange，提问作者angren