我正试图通过嵌入PresentationSource的ETW提供程序来跟踪WPF操作。当我跟踪实际应用程序时，我被已经触发的操作Id从Post阶段更改为Start阶段所困扰。
在源代码中，我发现Id依赖于对象的地址，该地址可能在GC操作期间更改：https://referencesource.microsoft.com/#windowsbase/Base/System/Windows/Threading/DispatcherOperation.cs，dff34e59b0ffd1e
有人知道如何通过ETW跟踪这样的对象重新定位吗？
可能会跟踪此类移动
ProviderName:"Microsoft Windows DotNETRuntime">
EventName:"GC/GCBlkMovedObjectRanges">
事件可能由ClrTrackEventParser.GCBulkMovedObject Ranges 解析
最初的答案是：
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时有固定的地址位置，但整个操作并不能确保跟踪消息包含正确的地址。在引发事件时，它可能已被移动。
我得到了下一个事件序列：
-WClientUIContentPost
-GCBulkMovedObjectRanges
-VClientUIContext Post
最后一个可能包含感动或不感动的Id.只有神知道。
事件GCBulkMovedObjectRanges在95%的情况下可用。但有时它是失败的。
因此无法可靠地跟踪它。非常遗憾的是，这个体系结构/实现错误导致功能无法使用。