当通过嵌入式 ETW 提供程序跟踪 WPF 操作时，操作 ID 是可变的答案

【问题标题】：Operation Id is changeable when trace WPF operations by embedded ETW provider当通过嵌入式 ETW 提供程序跟踪 WPF 操作时，操作 ID 是可变的
【发布时间】：2019-04-23 00:05:24
【问题描述】：

我正在尝试通过嵌入到 PresentationSource 中的 ETW 提供程序跟踪 WPF 操作。当我跟踪实际应用程序时，我将已经触发的操作 ID 从 Post 更改为 Start 阶段。

在源代码中，我发现 Id 依赖于可能在 GC 操作期间更改的对象的地址： https://referencesource.microsoft.com/#windowsbase/Base/System/Windows/Threading/DispatcherOperation.cs,dff34e59b0cffd1e

有人知道如何通过 ETW 跟踪此类对象重定位吗？

【问题讨论】：

标签： c# wpf garbage-collection dispatcher etw

【解决方案1】：

此类移动可能会被以下人员跟踪：

ProviderName：“Microsoft-Windows-DotNETRuntime”
事件名称：“GC/GCBulkMovedObjectRanges”
事件可能被 ClrTraceEventParser.GCBulkMovedObjectRanges 解析

原来是在那里回答的：

https://social.msdn.microsoft.com/Forums/en-US/7b6f9918-60ee-4e23-b443-42b4895775ad/how-to-track-change-of-wpf-dispatcheroperation-id?forum=netfxbcl

更新：

由于跟踪 WPF 操作，我会说具有可变 ID 的方法是有史以来最糟糕的实现。执行不正确。

Id 在收集该 Id 期间具有固定的地址位置，但整个操作并不能确保跟踪消息包含正确的地址。引发事件时，它可能已经被移动。

我得到了下一个事件序列：
- WClientUIContextPost
- GCBulkMovedObjectRanges
- WClientUIContextPost

最后一个可能包含已移动或未移动的 Id。只有神知道。

事件 GCBulkMovedObjectRanges 可用率达到 95%。但有时它会失败。

所以它没有办法跟踪它是否可靠。非常遗憾的是，这种架构/实现错误导致功能无法使用。

【讨论】：