Идентификатор операции можно изменить, когда трассировка операций WPF выполняется встроенным поставщиком ETW. - PullRequest
Новая
       11

Идентификатор операции можно изменить, когда трассировка операций WPF выполняется встроенным поставщиком ETW.

0 голосов
/ 20 ноября 2018

Я пытаюсь отследить операции WPF провайдера ETW, встроенного в PresentationSource.Когда я отследил реальное приложение, я немного изменил уже запущенный Id операции с фазы Post на Start.

В исходном коде я обнаружил, что Id основан на адресе объекта, который может быть изменен во время операции GC: https://referencesource.microsoft.com/#windowsbase/Base/System/Windows/Threading/DispatcherOperation.cs,dff34e59b0cffd1e

Кто-нибудь знает, как ETW отследить такое перемещение объекта?

1 Ответ

0 голосов
/ 22 ноября 2018

Такое движение может отслеживаться:

ProviderName: "Microsoft-Windows-DotNETRuntime"
EventName: "GC / GCBulkMovedObjectRanges"
Событие может быть проанализировано ClrTraceEventParser.GCBulkMovedObjectRanges1006 * Первоначально там ответили:

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

ОБНОВЛЕНИЕ:

Из-за отслеживания операций WPF я бы сказал, чтоПодход с изменяемым идентификатором - худшая реализация.Он реализован неправильно.

Идентификатор имеет фиксированную позицию адреса во время сбора этого идентификатора, но вся операция не гарантирует, что сообщение трассировки содержит правильный адрес.Это может быть уже перемещено при возникновении события.

Я получил следующую последовательность событий:- WClientUIContextPost- GCBulkMovedObjectRanges- WClientUIContextPost

Где последний может содержать перемещенный или неизменный идентификатор.Только боги знают.

Событие GCBulkMovedObjectRanges можно использовать на 95%.Но иногда это терпит неудачу.

Так что невозможно отследить его надежно.Очень печально, что эта архитектурная ошибка / ошибка реализации стала непригодной для использования.

...