Отсутствует идентификатор ActivityId в событиях ETW, опубликованных из разных потоков

Итак, у меня есть служба WCF, которую я размещаю в консольном приложении на моей машине разработки. Я запускаю PerfView на том же компьютере для сбора событий ETW (отслеживание событий для Windows). Служба WCF использует TPL (параллельную библиотеку задач), и я пытаюсь сопоставить события ETW во всех потоках на протяжении всего времени существования запроса WCF. Я говорю строго о сервере, а не о клиенте и сервере. Однако, когда я просматриваю события в PerfView и фильтрую представление только для тех событий из моего пользовательского EventSource, только события в некоторых потоках имеют ActivityId. Для любого данного потока либо все события имеют ActivityId, либо ни одно из событий не имеет. Кроме того, ни одно из событий не имеет RelatedActivityId.

Эта ссылка относится к блоку приложения семантического ведения журнала (SLAB), но в нем упоминается, что:

При использовании задач TPL каждый поток получает свой собственный идентификатор действия, а код планирования TPL автоматически публикует события передачи, содержащие значения ActivityId и RelatedActivityId. Их можно использовать для корреляции связанных событий.

Мне кажется, это совсем не так. Я не только не вижу каких-либо событий передачи для сопоставления идентификаторов действий, но во многих случаях, как я упоминал ранее, идентификаторы действий вообще отсутствуют.

Согласно этому ответу SO: https://stackoverflow.com/a/27620321/1937249:

Если вы используете прослушиватели вне процесса, то возникает ошибка, что конфигурация TPL по имени не работает, и вместо нее должен использоваться GID: https://slab.codeplex.com/workitem/62

Поэтому я попытался добавить GUID источника события в «Дополнительные поставщики» PerfView вместо его имени, например:

Однако это не имело значения. Мои события были опубликованы, но многим из них все еще не хватало ActivityId, а всем событиям не хватало RelatedActivityId.

И последнее, что может иметь значение: я использую пространство имен Microsoft.Diagnostics.Tracing в пакете Microsoft.Diagnostics.Tracing.EventSource NuGet, а не System.Diagnostics.Tracing, встроенное в фреймворк.

ИЗМЕНИТЬ

Вот изображение, показывающее все типы событий, которые были захвачены из TplEventSource. Я предполагаю, что это означает, что TplEventSource включен. Мне не ясно, должен ли я видеть в списке «событие перевода» или одно из событий должно иметь ключевое слово или другое поле, указывающее, что это был перевод. Если предполагается фактическое «событие передачи», я не вижу ничего подобного в списке.

PerfView Вывод

Вот изображение списка событий из моего пользовательского EventSource для одного запроса WCF. Вы можете видеть, что запрос начинается с идентификатора потока 10 724. Каждое событие в этом потоке имеет ActivityId. «Asi-Geoservices/StartAuthenticateRequest/Start» выполняет асинхронный вызов базы данных, и приложение возобновляет работу в потоке 8268. Ни одно из событий в потоке 8268 не имеет ActivityId. 'Asi-Geoservices/StartServiceProviderRequest/Start' делает асинхронный HTTP-запрос, и приложение возобновляет работу в потоке 11 764, где, опять же, каждое событие в этом потоке имеет ActivityId. После «Asi-Geoservices/StartServiceProviderRequest/Stop» выполняется еще один асинхронный вызов базы данных, и приложение снова возобновляет работу в потоке 8268, где запрос в конечном итоге завершается, но на этот раз каждое событие в потоке теперь имеет ActivityId.