How to track change of WPF DispatcherOperation Id? RRS feed

  • Question

  • I'm trying to trace WPF application by embedded ETW provider.

    But faced with unpredicted behavior: Id is changed from Post to Start operation phase.

    Base on next comment it is intended: https://referencesource.microsoft.com/#windowsbase/Base/System/Windows/Threading/DispatcherOperation.cs,dff34e59b0cffd1e,references

    How to trace such movement by CLR ETW events?

    Tuesday, November 20, 2018 5:07 PM


All replies

  • Hi Evgeny_Burmakov,

    Sorry, I am not familiar with ETW provider, and I will involve senior member to join this thread, and this may take some time. 

    Thanks for your understanding. 

    Best regards,


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, November 21, 2018 2:28 AM
  • I have spent 2 days for finding a way but still without success.

    I have found how to trace Heap/Realloc event from HeapTraceProvider (what is definitely not trivial thing) but seems that it isn't what I need. Addresses from that event isn't crossed with Id's a bit (closer but not inside).

    Any hint is required!

    Wednesday, November 21, 2018 5:44 PM
  • I believe the comment refers to the GCBulkMovedObjectRanges event, which is supported by CoreCLR and PerfView, probably .NET Framework as well.

    The same information may be available via ICorProfilerCallback4::MovedReferences2.

    Thursday, November 22, 2018 8:11 AM
  • Hi Ranta,

    Thanks for the direction.

    At this event I don's see information enough for actualize Id's.

    There is example of traced event:

    <Event MSec=   "434.9929" PID="14412" PName=        "" TID="8476" EventName="GC/GCBulkMovedObjectRanges" ProviderName="Microsoft-Windows-DotNETRuntime" FormattedMessage="ClrInstanceID=0;
    Count=11 " Index="0" Count="835" ClrInstanceID="11"/>



    The data available internally at the message. Let's check is is sufficient.

    Thursday, November 22, 2018 9:45 AM
  • You are right! It is the required event. All operations are matched now.



    Event might be parsed by ClrTraceEventParser.GCBulkMovedObjectRanges

    Thursday, November 22, 2018 12:49 PM
  • Due to tracing WPF operations I would say that approach with changeable ID is worst ever implementation. It is implemented incorrectly.

    Id has fixed address position during gather that Id but whole operation isn't ensure that tracing message contains correct address. It might be already moved when event is raised.

    I got next event sequence:
    - WClientUIContextPost
    - GCBulkMovedObjectRanges
    - WClientUIContextPost

    Where last one may contains moved or unmoved Id. Only gods know.

    The event GCBulkMovedObjectRanges is usable in 95%. But sometimes it is fails.

    So it no way to track it reliable. Very sadly that this architectural/implementation mistake turn feature unusable.

    Thursday, November 29, 2018 10:05 AM