Update provider_compute_event_enable_mask so EventSouces with no keywords show up by default by davmason · Pull Request #75248 · dotnet/runtime

davmason · 2022-09-08T08:52:24Z

EventSource uses bits 44-47 of the keywords to store data about sessions:

runtime/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs

Lines 5071 to 5073 in 01d1c8c

internalconstintSHIFT_SESSION_TO_KEYWORD=44;// bits 44-47 inclusive are reserved
internalconstuintMASK=0x0fU;// the mask of 4 reserved bits
internalconstuintMAX=4;// maximum number of simultaneous ETW sessions supported

And we set them all to 1 by default in the manifest:

runtime/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs

Lines 3428 to 3439 in 01d1c8c

 metadata.Descriptor=newEventDescriptor(
eventAttribute.EventId,
eventAttribute.Version,
 #if FEATURE_MANAGED_ETW_CHANNELS
(byte)eventAttribute.Channel,
 #else 
(byte)0,
 #endif 
(byte)eventAttribute.Level,
(byte)eventAttribute.Opcode,
(int)eventAttribute.Task,
unchecked((long)((ulong)eventAttribute.Keywords|SessionMask.All.ToEventKeywords())));

This means that when we compute whether an event should be enabled we won't turn on EventSource events by default, since the event keywords are non-zero 0xF00000000000:

runtime/src/native/eventpipe/ep-provider.c

Line 152 in 01d1c8c

boolkeyword_enabled= (keywords==0) || ((session_keyword&keywords) !=0);

We have a workaround in the DiagnosticClient introduced here: dotnet/diagnostics#1091, but any other way of enabling EventPipe (env vars, other clients, etc) will still have this issue.

This fix lets the default EventSource keyword act as if it were 0 for all sessions.

This does have two compat issues

If someone has a provider that was using any of the masked bits it would now start to show up in traces that didn't have the keyword set
We cannot use those keywords for runtime events, our current high bit is 42 0x20000000000 so we are very close to that number. I don't think we have a choice regardless of this change though, due to EventSource treating those bits as reserved.

lateralusX

LGTM!

noahfalk · 2022-09-09T04:17:44Z

 int64_t session_keyword = ep_session_provider_get_keywords (session_provider);
 EventPipeEventLevel session_level = ep_session_provider_get_logging_level (session_provider);
+ // EventSources always set 0xF00000000000 to signify no keywords 
+ int64_t session_mask = ~0xF00000000000;


Rather than do this filtering at the point of use, how about we filter these keyword bits at the point we are initializing the event in provider_add_event?

noahfalk · 2022-09-09T04:28:28Z

We have a workaround in the DiagnosticClient introduced here: dotnet/diagnostics#1091

Rats, I missed when this change went in. I may be unaware of constraints Sung was under when he did that, but this change you have here looks like a much better approach.

noahfalk · 2022-09-09T04:31:30Z

If someone has a provider that was using any of the masked bits it would now start to show up in traces that didn't have the keyword set

If they did that they would already be seeing weird behavior under ETW. Its possible someone does it and never uses their EventSource with ETW, but the odds of that seem low enough that I am willing to risk inconveniencing them.

mikelle-rogers · 2022-09-28T16:37:39Z

Is there documentation that needs to be updated with this change?

davmason · 2022-09-30T11:16:56Z

@mikelle-rogers no documentation needed, this is making things work as already documented

davmason · 2022-10-01T10:40:13Z

I found out via failing tests that -1 as a keyword is special and we can't modify it, so I added that check

adamsitnik · 2022-10-04T10:48:18Z

@davmason are you going to backport this PR to 7 and 6?

davmason · 2022-10-11T08:37:03Z

@adamsitnik do you know of any customers that are asking for it? I'm happy to go through the process but the servicing bar requires a customer blocked on it

adamsitnik · 2022-10-11T12:10:52Z

@davmason From my perspective I wonder if this related to microsoft/perfview#1718

do you know of any customers that are asking for it?

@tmds ?

davmason · 2022-10-11T20:19:26Z

@davmason From my perspective I wonder if this related to microsoft/perfview#1718

Yes, that looks like the same issue. Trying to collect EventSources using the environment variables is broken. You can work around by either using dotnet-trace to collect instead, or setting keywords to 0xFFFFFFFF for any EventSources you want events from.

If we have people asking for the fix just point them to me and I can start the servicing process

adamsitnik · 2022-10-11T20:26:40Z

Yes, that looks like the same issue.
If we have people asking for the fix just point them to me and I can start the servicing process

Then this would be me as I want to publish a new BenchmarkDotNet version with the PerfCollectDiagnoser (dotnet/BenchmarkDotNet#2117). It's a plugin that does allow for profiling with perfcollect during the benchmarking (we already have sth like that for EventPipe, but it's missing the native call stack info which is often important).

I need the BDN events to be able to tell when given benchmark iteration started and finished to be able to implement detection of regression on top of it. This year I am aiming at adding a BDN feature where the user just specifies the benchmark that has regressed between .NET releases, BDN runs it with profiler attached, loads the trace file using Trace Event, filters it based on the events to selected time frame and then uses Trace Event to diff the traces and just tell the user where the regression is.

davmason · 2022-10-13T21:58:50Z

I'm happy to take it to servicing if that is the best outcome, but the next servicing date is in January so no fixes would be available until then. I suspect it will work better for you to find a workaround

Are you able to use the diagnostics client instead of the environment variables? https://learn.microsoft.com/en-us/dotnet/core/diagnostics/diagnostics-client-library

There is already a workaround in that library and you wouldn't have to wait on any servicing fixes, the client and runtime support attaching to your own process and attaching at startup, so it should work for most scenarios

…ords show up by default (dotnet#75248) Update ep-provider.c

…Pipe sessions (#75248) (#77811) * Update provider_compute_event_enable_mask so EventSouces with no keywords show up by default (#75248) Update ep-provider.c * Update ep-provider.c * Update src/native/eventpipe/ep-provider.c Co-authored-by: Juan Hoyos <juan.hoyos@microsoft.com> Co-authored-by: Juan Hoyos <juan.hoyos@microsoft.com>

davmason · 2022-09-08T08:52:24Z

Fixesdotnet/diagnostics#3298

EventSource uses bits 44-47 of the keywords to store data about sessions:

runtime/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs

Lines 5071 to 5073 in 01d1c8c

internalconstintSHIFT_SESSION_TO_KEYWORD=44;// bits 44-47 inclusive are reserved
internalconstuintMASK=0x0fU;// the mask of 4 reserved bits
internalconstuintMAX=4;// maximum number of simultaneous ETW sessions supported

And we set them all to 1 by default in the manifest:

runtime/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs

Lines 3428 to 3439 in 01d1c8c

 metadata.Descriptor=newEventDescriptor(
eventAttribute.EventId,
eventAttribute.Version,
 #if FEATURE_MANAGED_ETW_CHANNELS
(byte)eventAttribute.Channel,
 #else 
(byte)0,
 #endif 
(byte)eventAttribute.Level,
(byte)eventAttribute.Opcode,
(int)eventAttribute.Task,
unchecked((long)((ulong)eventAttribute.Keywords|SessionMask.All.ToEventKeywords())));

This means that when we compute whether an event should be enabled we won't turn on EventSource events by default, since the event keywords are non-zero 0xF00000000000:

runtime/src/native/eventpipe/ep-provider.c

Line 152 in 01d1c8c

boolkeyword_enabled= (keywords==0) || ((session_keyword&keywords) !=0);

We have a workaround in the DiagnosticClient introduced here: dotnet/diagnostics#1091, but any other way of enabling EventPipe (env vars, other clients, etc) will still have this issue.

This fix lets the default EventSource keyword act as if it were 0 for all sessions.

This does have two compat issues

If someone has a provider that was using any of the masked bits it would now start to show up in traces that didn't have the keyword set
We cannot use those keywords for runtime events, our current high bit is 42 0x20000000000 so we are very close to that number. I don't think we have a choice regardless of this change though, due to EventSource treating those bits as reserved.

lateralusX

LGTM!

noahfalk · 2022-09-09T04:17:44Z

 int64_t session_keyword = ep_session_provider_get_keywords (session_provider);
 EventPipeEventLevel session_level = ep_session_provider_get_logging_level (session_provider);
+ // EventSources always set 0xF00000000000 to signify no keywords 
+ int64_t session_mask = ~0xF00000000000;


Rather than do this filtering at the point of use, how about we filter these keyword bits at the point we are initializing the event in provider_add_event?

noahfalk · 2022-09-09T04:28:28Z

We have a workaround in the DiagnosticClient introduced here: dotnet/diagnostics#1091

Rats, I missed when this change went in. I may be unaware of constraints Sung was under when he did that, but this change you have here looks like a much better approach.

noahfalk · 2022-09-09T04:31:30Z

If someone has a provider that was using any of the masked bits it would now start to show up in traces that didn't have the keyword set

If they did that they would already be seeing weird behavior under ETW. Its possible someone does it and never uses their EventSource with ETW, but the odds of that seem low enough that I am willing to risk inconveniencing them.

mikelle-rogers · 2022-09-28T16:37:39Z

Is there documentation that needs to be updated with this change?

davmason · 2022-09-30T11:16:56Z

@mikelle-rogers no documentation needed, this is making things work as already documented

davmason · 2022-10-01T10:40:13Z

I found out via failing tests that -1 as a keyword is special and we can't modify it, so I added that check

adamsitnik · 2022-10-04T10:48:18Z

@davmason are you going to backport this PR to 7 and 6?

davmason · 2022-10-11T08:37:03Z

@adamsitnik do you know of any customers that are asking for it? I'm happy to go through the process but the servicing bar requires a customer blocked on it

adamsitnik · 2022-10-11T12:10:52Z

@davmason From my perspective I wonder if this related to microsoft/perfview#1718

do you know of any customers that are asking for it?

@tmds ?

davmason · 2022-10-11T20:19:26Z

@davmason From my perspective I wonder if this related to microsoft/perfview#1718

Yes, that looks like the same issue. Trying to collect EventSources using the environment variables is broken. You can work around by either using dotnet-trace to collect instead, or setting keywords to 0xFFFFFFFF for any EventSources you want events from.

If we have people asking for the fix just point them to me and I can start the servicing process

adamsitnik · 2022-10-11T20:26:40Z

Yes, that looks like the same issue.
If we have people asking for the fix just point them to me and I can start the servicing process

Then this would be me as I want to publish a new BenchmarkDotNet version with the PerfCollectDiagnoser (dotnet/BenchmarkDotNet#2117). It's a plugin that does allow for profiling with perfcollect during the benchmarking (we already have sth like that for EventPipe, but it's missing the native call stack info which is often important).

I need the BDN events to be able to tell when given benchmark iteration started and finished to be able to implement detection of regression on top of it. This year I am aiming at adding a BDN feature where the user just specifies the benchmark that has regressed between .NET releases, BDN runs it with profiler attached, loads the trace file using Trace Event, filters it based on the events to selected time frame and then uses Trace Event to diff the traces and just tell the user where the regression is.

davmason · 2022-10-13T21:58:50Z

I'm happy to take it to servicing if that is the best outcome, but the next servicing date is in January so no fixes would be available until then. I suspect it will work better for you to find a workaround

Are you able to use the diagnostics client instead of the environment variables? https://learn.microsoft.com/en-us/dotnet/core/diagnostics/diagnostics-client-library

There is already a workaround in that library and you wouldn't have to wait on any servicing fixes, the client and runtime support attaching to your own process and attaching at startup, so it should work for most scenarios

…ords show up by default (dotnet#75248) Update ep-provider.c

…Pipe sessions (#75248) (#77811) * Update provider_compute_event_enable_mask so EventSouces with no keywords show up by default (#75248) Update ep-provider.c * Update ep-provider.c * Update src/native/eventpipe/ep-provider.c Co-authored-by: Juan Hoyos <juan.hoyos@microsoft.com> Co-authored-by: Juan Hoyos <juan.hoyos@microsoft.com>

davmason · 2022-09-08T08:52:24Z

Fixesdotnet/diagnostics#3298

EventSource uses bits 44-47 of the keywords to store data about sessions:

runtime/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs

Lines 5071 to 5073 in 01d1c8c

internalconstintSHIFT_SESSION_TO_KEYWORD=44;// bits 44-47 inclusive are reserved
internalconstuintMASK=0x0fU;// the mask of 4 reserved bits
internalconstuintMAX=4;// maximum number of simultaneous ETW sessions supported

And we set them all to 1 by default in the manifest:

runtime/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs

Lines 3428 to 3439 in 01d1c8c

 metadata.Descriptor=newEventDescriptor(
eventAttribute.EventId,
eventAttribute.Version,
 #if FEATURE_MANAGED_ETW_CHANNELS
(byte)eventAttribute.Channel,
 #else 
(byte)0,
 #endif 
(byte)eventAttribute.Level,
(byte)eventAttribute.Opcode,
(int)eventAttribute.Task,
unchecked((long)((ulong)eventAttribute.Keywords|SessionMask.All.ToEventKeywords())));

This means that when we compute whether an event should be enabled we won't turn on EventSource events by default, since the event keywords are non-zero 0xF00000000000:

runtime/src/native/eventpipe/ep-provider.c

Line 152 in 01d1c8c

boolkeyword_enabled= (keywords==0) || ((session_keyword&keywords) !=0);

We have a workaround in the DiagnosticClient introduced here: dotnet/diagnostics#1091, but any other way of enabling EventPipe (env vars, other clients, etc) will still have this issue.

This fix lets the default EventSource keyword act as if it were 0 for all sessions.

This does have two compat issues

If someone has a provider that was using any of the masked bits it would now start to show up in traces that didn't have the keyword set
We cannot use those keywords for runtime events, our current high bit is 42 0x20000000000 so we are very close to that number. I don't think we have a choice regardless of this change though, due to EventSource treating those bits as reserved.

lateralusX

LGTM!

noahfalk · 2022-09-09T04:17:44Z

 int64_t session_keyword = ep_session_provider_get_keywords (session_provider);
 EventPipeEventLevel session_level = ep_session_provider_get_logging_level (session_provider);
+ // EventSources always set 0xF00000000000 to signify no keywords 
+ int64_t session_mask = ~0xF00000000000;


Rather than do this filtering at the point of use, how about we filter these keyword bits at the point we are initializing the event in provider_add_event?

noahfalk · 2022-09-09T04:28:28Z

We have a workaround in the DiagnosticClient introduced here: dotnet/diagnostics#1091

Rats, I missed when this change went in. I may be unaware of constraints Sung was under when he did that, but this change you have here looks like a much better approach.

noahfalk · 2022-09-09T04:31:30Z

If someone has a provider that was using any of the masked bits it would now start to show up in traces that didn't have the keyword set

If they did that they would already be seeing weird behavior under ETW. Its possible someone does it and never uses their EventSource with ETW, but the odds of that seem low enough that I am willing to risk inconveniencing them.

mikelle-rogers · 2022-09-28T16:37:39Z

Is there documentation that needs to be updated with this change?

davmason · 2022-09-30T11:16:56Z

@mikelle-rogers no documentation needed, this is making things work as already documented

davmason · 2022-10-01T10:40:13Z

I found out via failing tests that -1 as a keyword is special and we can't modify it, so I added that check

adamsitnik · 2022-10-04T10:48:18Z

@davmason are you going to backport this PR to 7 and 6?

davmason · 2022-10-11T08:37:03Z

@adamsitnik do you know of any customers that are asking for it? I'm happy to go through the process but the servicing bar requires a customer blocked on it

adamsitnik · 2022-10-11T12:10:52Z

@davmason From my perspective I wonder if this related to microsoft/perfview#1718

do you know of any customers that are asking for it?

@tmds ?

davmason · 2022-10-11T20:19:26Z

@davmason From my perspective I wonder if this related to microsoft/perfview#1718

Yes, that looks like the same issue. Trying to collect EventSources using the environment variables is broken. You can work around by either using dotnet-trace to collect instead, or setting keywords to 0xFFFFFFFF for any EventSources you want events from.

If we have people asking for the fix just point them to me and I can start the servicing process

adamsitnik · 2022-10-11T20:26:40Z

Yes, that looks like the same issue.
If we have people asking for the fix just point them to me and I can start the servicing process

Then this would be me as I want to publish a new BenchmarkDotNet version with the PerfCollectDiagnoser (dotnet/BenchmarkDotNet#2117). It's a plugin that does allow for profiling with perfcollect during the benchmarking (we already have sth like that for EventPipe, but it's missing the native call stack info which is often important).

I need the BDN events to be able to tell when given benchmark iteration started and finished to be able to implement detection of regression on top of it. This year I am aiming at adding a BDN feature where the user just specifies the benchmark that has regressed between .NET releases, BDN runs it with profiler attached, loads the trace file using Trace Event, filters it based on the events to selected time frame and then uses Trace Event to diff the traces and just tell the user where the regression is.

davmason · 2022-10-13T21:58:50Z

I'm happy to take it to servicing if that is the best outcome, but the next servicing date is in January so no fixes would be available until then. I suspect it will work better for you to find a workaround

Are you able to use the diagnostics client instead of the environment variables? https://learn.microsoft.com/en-us/dotnet/core/diagnostics/diagnostics-client-library

There is already a workaround in that library and you wouldn't have to wait on any servicing fixes, the client and runtime support attaching to your own process and attaching at startup, so it should work for most scenarios

…ords show up by default (dotnet#75248) Update ep-provider.c

…Pipe sessions (#75248) (#77811) * Update provider_compute_event_enable_mask so EventSouces with no keywords show up by default (#75248) Update ep-provider.c * Update ep-provider.c * Update src/native/eventpipe/ep-provider.c Co-authored-by: Juan Hoyos <juan.hoyos@microsoft.com> Co-authored-by: Juan Hoyos <juan.hoyos@microsoft.com>

davmason · 2022-09-08T08:52:24Z

Fixesdotnet/diagnostics#3298

EventSource uses bits 44-47 of the keywords to store data about sessions:

runtime/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs

Lines 5071 to 5073 in 01d1c8c

internalconstintSHIFT_SESSION_TO_KEYWORD=44;// bits 44-47 inclusive are reserved
internalconstuintMASK=0x0fU;// the mask of 4 reserved bits
internalconstuintMAX=4;// maximum number of simultaneous ETW sessions supported

And we set them all to 1 by default in the manifest:

runtime/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs

Lines 3428 to 3439 in 01d1c8c

 metadata.Descriptor=newEventDescriptor(
eventAttribute.EventId,
eventAttribute.Version,
 #if FEATURE_MANAGED_ETW_CHANNELS
(byte)eventAttribute.Channel,
 #else 
(byte)0,
 #endif 
(byte)eventAttribute.Level,
(byte)eventAttribute.Opcode,
(int)eventAttribute.Task,
unchecked((long)((ulong)eventAttribute.Keywords|SessionMask.All.ToEventKeywords())));

This means that when we compute whether an event should be enabled we won't turn on EventSource events by default, since the event keywords are non-zero 0xF00000000000:

runtime/src/native/eventpipe/ep-provider.c

Line 152 in 01d1c8c

boolkeyword_enabled= (keywords==0) || ((session_keyword&keywords) !=0);

We have a workaround in the DiagnosticClient introduced here: dotnet/diagnostics#1091, but any other way of enabling EventPipe (env vars, other clients, etc) will still have this issue.

This fix lets the default EventSource keyword act as if it were 0 for all sessions.

This does have two compat issues

If someone has a provider that was using any of the masked bits it would now start to show up in traces that didn't have the keyword set
We cannot use those keywords for runtime events, our current high bit is 42 0x20000000000 so we are very close to that number. I don't think we have a choice regardless of this change though, due to EventSource treating those bits as reserved.

lateralusX

LGTM!

noahfalk · 2022-09-09T04:17:44Z

 int64_t session_keyword = ep_session_provider_get_keywords (session_provider);
 EventPipeEventLevel session_level = ep_session_provider_get_logging_level (session_provider);
+ // EventSources always set 0xF00000000000 to signify no keywords 
+ int64_t session_mask = ~0xF00000000000;


Rather than do this filtering at the point of use, how about we filter these keyword bits at the point we are initializing the event in provider_add_event?

noahfalk · 2022-09-09T04:28:28Z

We have a workaround in the DiagnosticClient introduced here: dotnet/diagnostics#1091

Rats, I missed when this change went in. I may be unaware of constraints Sung was under when he did that, but this change you have here looks like a much better approach.

noahfalk · 2022-09-09T04:31:30Z

If someone has a provider that was using any of the masked bits it would now start to show up in traces that didn't have the keyword set

If they did that they would already be seeing weird behavior under ETW. Its possible someone does it and never uses their EventSource with ETW, but the odds of that seem low enough that I am willing to risk inconveniencing them.

mikelle-rogers · 2022-09-28T16:37:39Z

Is there documentation that needs to be updated with this change?

davmason · 2022-09-30T11:16:56Z

@mikelle-rogers no documentation needed, this is making things work as already documented

davmason · 2022-10-01T10:40:13Z

I found out via failing tests that -1 as a keyword is special and we can't modify it, so I added that check

adamsitnik · 2022-10-04T10:48:18Z

@davmason are you going to backport this PR to 7 and 6?

davmason · 2022-10-11T08:37:03Z

@adamsitnik do you know of any customers that are asking for it? I'm happy to go through the process but the servicing bar requires a customer blocked on it

adamsitnik · 2022-10-11T12:10:52Z

@davmason From my perspective I wonder if this related to microsoft/perfview#1718

do you know of any customers that are asking for it?

@tmds ?

davmason · 2022-10-11T20:19:26Z

@davmason From my perspective I wonder if this related to microsoft/perfview#1718

Yes, that looks like the same issue. Trying to collect EventSources using the environment variables is broken. You can work around by either using dotnet-trace to collect instead, or setting keywords to 0xFFFFFFFF for any EventSources you want events from.

If we have people asking for the fix just point them to me and I can start the servicing process

adamsitnik · 2022-10-11T20:26:40Z

Yes, that looks like the same issue.
If we have people asking for the fix just point them to me and I can start the servicing process

Then this would be me as I want to publish a new BenchmarkDotNet version with the PerfCollectDiagnoser (dotnet/BenchmarkDotNet#2117). It's a plugin that does allow for profiling with perfcollect during the benchmarking (we already have sth like that for EventPipe, but it's missing the native call stack info which is often important).

I need the BDN events to be able to tell when given benchmark iteration started and finished to be able to implement detection of regression on top of it. This year I am aiming at adding a BDN feature where the user just specifies the benchmark that has regressed between .NET releases, BDN runs it with profiler attached, loads the trace file using Trace Event, filters it based on the events to selected time frame and then uses Trace Event to diff the traces and just tell the user where the regression is.

davmason · 2022-10-13T21:58:50Z

I'm happy to take it to servicing if that is the best outcome, but the next servicing date is in January so no fixes would be available until then. I suspect it will work better for you to find a workaround

Are you able to use the diagnostics client instead of the environment variables? https://learn.microsoft.com/en-us/dotnet/core/diagnostics/diagnostics-client-library

There is already a workaround in that library and you wouldn't have to wait on any servicing fixes, the client and runtime support attaching to your own process and attaching at startup, so it should work for most scenarios

…ords show up by default (dotnet#75248) Update ep-provider.c

…Pipe sessions (#75248) (#77811) * Update provider_compute_event_enable_mask so EventSouces with no keywords show up by default (#75248) Update ep-provider.c * Update ep-provider.c * Update src/native/eventpipe/ep-provider.c Co-authored-by: Juan Hoyos <juan.hoyos@microsoft.com> Co-authored-by: Juan Hoyos <juan.hoyos@microsoft.com>

davmason · 2022-09-08T08:52:24Z

Fixesdotnet/diagnostics#3298

EventSource uses bits 44-47 of the keywords to store data about sessions:

runtime/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs

Lines 5071 to 5073 in 01d1c8c

internalconstintSHIFT_SESSION_TO_KEYWORD=44;// bits 44-47 inclusive are reserved
internalconstuintMASK=0x0fU;// the mask of 4 reserved bits
internalconstuintMAX=4;// maximum number of simultaneous ETW sessions supported

And we set them all to 1 by default in the manifest:

runtime/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs

Lines 3428 to 3439 in 01d1c8c

 metadata.Descriptor=newEventDescriptor(
eventAttribute.EventId,
eventAttribute.Version,
 #if FEATURE_MANAGED_ETW_CHANNELS
(byte)eventAttribute.Channel,
 #else 
(byte)0,
 #endif 
(byte)eventAttribute.Level,
(byte)eventAttribute.Opcode,
(int)eventAttribute.Task,
unchecked((long)((ulong)eventAttribute.Keywords|SessionMask.All.ToEventKeywords())));

This means that when we compute whether an event should be enabled we won't turn on EventSource events by default, since the event keywords are non-zero 0xF00000000000:

runtime/src/native/eventpipe/ep-provider.c

Line 152 in 01d1c8c

boolkeyword_enabled= (keywords==0) || ((session_keyword&keywords) !=0);

We have a workaround in the DiagnosticClient introduced here: dotnet/diagnostics#1091, but any other way of enabling EventPipe (env vars, other clients, etc) will still have this issue.

This fix lets the default EventSource keyword act as if it were 0 for all sessions.

This does have two compat issues

If someone has a provider that was using any of the masked bits it would now start to show up in traces that didn't have the keyword set
We cannot use those keywords for runtime events, our current high bit is 42 0x20000000000 so we are very close to that number. I don't think we have a choice regardless of this change though, due to EventSource treating those bits as reserved.

lateralusX

LGTM!

noahfalk · 2022-09-09T04:17:44Z

 int64_t session_keyword = ep_session_provider_get_keywords (session_provider);
 EventPipeEventLevel session_level = ep_session_provider_get_logging_level (session_provider);
+ // EventSources always set 0xF00000000000 to signify no keywords 
+ int64_t session_mask = ~0xF00000000000;


Rather than do this filtering at the point of use, how about we filter these keyword bits at the point we are initializing the event in provider_add_event?

noahfalk · 2022-09-09T04:28:28Z

We have a workaround in the DiagnosticClient introduced here: dotnet/diagnostics#1091

Rats, I missed when this change went in. I may be unaware of constraints Sung was under when he did that, but this change you have here looks like a much better approach.

noahfalk · 2022-09-09T04:31:30Z

If someone has a provider that was using any of the masked bits it would now start to show up in traces that didn't have the keyword set

If they did that they would already be seeing weird behavior under ETW. Its possible someone does it and never uses their EventSource with ETW, but the odds of that seem low enough that I am willing to risk inconveniencing them.

mikelle-rogers · 2022-09-28T16:37:39Z

Is there documentation that needs to be updated with this change?

davmason · 2022-09-30T11:16:56Z

@mikelle-rogers no documentation needed, this is making things work as already documented

davmason · 2022-10-01T10:40:13Z

I found out via failing tests that -1 as a keyword is special and we can't modify it, so I added that check

adamsitnik · 2022-10-04T10:48:18Z

@davmason are you going to backport this PR to 7 and 6?

davmason · 2022-10-11T08:37:03Z

@adamsitnik do you know of any customers that are asking for it? I'm happy to go through the process but the servicing bar requires a customer blocked on it

adamsitnik · 2022-10-11T12:10:52Z

@davmason From my perspective I wonder if this related to microsoft/perfview#1718

do you know of any customers that are asking for it?

@tmds ?

davmason · 2022-10-11T20:19:26Z

@davmason From my perspective I wonder if this related to microsoft/perfview#1718

Yes, that looks like the same issue. Trying to collect EventSources using the environment variables is broken. You can work around by either using dotnet-trace to collect instead, or setting keywords to 0xFFFFFFFF for any EventSources you want events from.

If we have people asking for the fix just point them to me and I can start the servicing process

adamsitnik · 2022-10-11T20:26:40Z

Yes, that looks like the same issue.
If we have people asking for the fix just point them to me and I can start the servicing process

Then this would be me as I want to publish a new BenchmarkDotNet version with the PerfCollectDiagnoser (dotnet/BenchmarkDotNet#2117). It's a plugin that does allow for profiling with perfcollect during the benchmarking (we already have sth like that for EventPipe, but it's missing the native call stack info which is often important).

I need the BDN events to be able to tell when given benchmark iteration started and finished to be able to implement detection of regression on top of it. This year I am aiming at adding a BDN feature where the user just specifies the benchmark that has regressed between .NET releases, BDN runs it with profiler attached, loads the trace file using Trace Event, filters it based on the events to selected time frame and then uses Trace Event to diff the traces and just tell the user where the regression is.

davmason · 2022-10-13T21:58:50Z

I'm happy to take it to servicing if that is the best outcome, but the next servicing date is in January so no fixes would be available until then. I suspect it will work better for you to find a workaround

Are you able to use the diagnostics client instead of the environment variables? https://learn.microsoft.com/en-us/dotnet/core/diagnostics/diagnostics-client-library

There is already a workaround in that library and you wouldn't have to wait on any servicing fixes, the client and runtime support attaching to your own process and attaching at startup, so it should work for most scenarios

…ords show up by default (dotnet#75248) Update ep-provider.c

…Pipe sessions (#75248) (#77811) * Update provider_compute_event_enable_mask so EventSouces with no keywords show up by default (#75248) Update ep-provider.c * Update ep-provider.c * Update src/native/eventpipe/ep-provider.c Co-authored-by: Juan Hoyos <juan.hoyos@microsoft.com> Co-authored-by: Juan Hoyos <juan.hoyos@microsoft.com>

davmason · 2022-09-08T08:52:24Z

Fixesdotnet/diagnostics#3298

EventSource uses bits 44-47 of the keywords to store data about sessions:

runtime/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs

Lines 5071 to 5073 in 01d1c8c

internalconstintSHIFT_SESSION_TO_KEYWORD=44;// bits 44-47 inclusive are reserved
internalconstuintMASK=0x0fU;// the mask of 4 reserved bits
internalconstuintMAX=4;// maximum number of simultaneous ETW sessions supported

And we set them all to 1 by default in the manifest:

runtime/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs

Lines 3428 to 3439 in 01d1c8c

 metadata.Descriptor=newEventDescriptor(
eventAttribute.EventId,
eventAttribute.Version,
 #if FEATURE_MANAGED_ETW_CHANNELS
(byte)eventAttribute.Channel,
 #else 
(byte)0,
 #endif 
(byte)eventAttribute.Level,
(byte)eventAttribute.Opcode,
(int)eventAttribute.Task,
unchecked((long)((ulong)eventAttribute.Keywords|SessionMask.All.ToEventKeywords())));

This means that when we compute whether an event should be enabled we won't turn on EventSource events by default, since the event keywords are non-zero 0xF00000000000:

runtime/src/native/eventpipe/ep-provider.c

Line 152 in 01d1c8c

boolkeyword_enabled= (keywords==0) || ((session_keyword&keywords) !=0);

We have a workaround in the DiagnosticClient introduced here: dotnet/diagnostics#1091, but any other way of enabling EventPipe (env vars, other clients, etc) will still have this issue.

This fix lets the default EventSource keyword act as if it were 0 for all sessions.

This does have two compat issues

If someone has a provider that was using any of the masked bits it would now start to show up in traces that didn't have the keyword set
We cannot use those keywords for runtime events, our current high bit is 42 0x20000000000 so we are very close to that number. I don't think we have a choice regardless of this change though, due to EventSource treating those bits as reserved.

lateralusX

LGTM!

noahfalk · 2022-09-09T04:17:44Z

 int64_t session_keyword = ep_session_provider_get_keywords (session_provider);
 EventPipeEventLevel session_level = ep_session_provider_get_logging_level (session_provider);
+ // EventSources always set 0xF00000000000 to signify no keywords 
+ int64_t session_mask = ~0xF00000000000;


Rather than do this filtering at the point of use, how about we filter these keyword bits at the point we are initializing the event in provider_add_event?

noahfalk · 2022-09-09T04:28:28Z

We have a workaround in the DiagnosticClient introduced here: dotnet/diagnostics#1091

Rats, I missed when this change went in. I may be unaware of constraints Sung was under when he did that, but this change you have here looks like a much better approach.

noahfalk · 2022-09-09T04:31:30Z

If someone has a provider that was using any of the masked bits it would now start to show up in traces that didn't have the keyword set

If they did that they would already be seeing weird behavior under ETW. Its possible someone does it and never uses their EventSource with ETW, but the odds of that seem low enough that I am willing to risk inconveniencing them.

mikelle-rogers · 2022-09-28T16:37:39Z

Is there documentation that needs to be updated with this change?

davmason · 2022-09-30T11:16:56Z

@mikelle-rogers no documentation needed, this is making things work as already documented

davmason · 2022-10-01T10:40:13Z

I found out via failing tests that -1 as a keyword is special and we can't modify it, so I added that check

adamsitnik · 2022-10-04T10:48:18Z

@davmason are you going to backport this PR to 7 and 6?

davmason · 2022-10-11T08:37:03Z

@adamsitnik do you know of any customers that are asking for it? I'm happy to go through the process but the servicing bar requires a customer blocked on it

adamsitnik · 2022-10-11T12:10:52Z

@davmason From my perspective I wonder if this related to microsoft/perfview#1718

do you know of any customers that are asking for it?

@tmds ?

davmason · 2022-10-11T20:19:26Z

@davmason From my perspective I wonder if this related to microsoft/perfview#1718

Yes, that looks like the same issue. Trying to collect EventSources using the environment variables is broken. You can work around by either using dotnet-trace to collect instead, or setting keywords to 0xFFFFFFFF for any EventSources you want events from.

If we have people asking for the fix just point them to me and I can start the servicing process

adamsitnik · 2022-10-11T20:26:40Z

Yes, that looks like the same issue.
If we have people asking for the fix just point them to me and I can start the servicing process

Then this would be me as I want to publish a new BenchmarkDotNet version with the PerfCollectDiagnoser (dotnet/BenchmarkDotNet#2117). It's a plugin that does allow for profiling with perfcollect during the benchmarking (we already have sth like that for EventPipe, but it's missing the native call stack info which is often important).

I need the BDN events to be able to tell when given benchmark iteration started and finished to be able to implement detection of regression on top of it. This year I am aiming at adding a BDN feature where the user just specifies the benchmark that has regressed between .NET releases, BDN runs it with profiler attached, loads the trace file using Trace Event, filters it based on the events to selected time frame and then uses Trace Event to diff the traces and just tell the user where the regression is.

davmason · 2022-10-13T21:58:50Z

I'm happy to take it to servicing if that is the best outcome, but the next servicing date is in January so no fixes would be available until then. I suspect it will work better for you to find a workaround

Are you able to use the diagnostics client instead of the environment variables? https://learn.microsoft.com/en-us/dotnet/core/diagnostics/diagnostics-client-library

There is already a workaround in that library and you wouldn't have to wait on any servicing fixes, the client and runtime support attaching to your own process and attaching at startup, so it should work for most scenarios

…ords show up by default (dotnet#75248) Update ep-provider.c

…Pipe sessions (#75248) (#77811) * Update provider_compute_event_enable_mask so EventSouces with no keywords show up by default (#75248) Update ep-provider.c * Update ep-provider.c * Update src/native/eventpipe/ep-provider.c Co-authored-by: Juan Hoyos <juan.hoyos@microsoft.com> Co-authored-by: Juan Hoyos <juan.hoyos@microsoft.com>

davmason · 2022-09-08T08:52:24Z

Fixesdotnet/diagnostics#3298

EventSource uses bits 44-47 of the keywords to store data about sessions:

runtime/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs

Lines 5071 to 5073 in 01d1c8c

internalconstintSHIFT_SESSION_TO_KEYWORD=44;// bits 44-47 inclusive are reserved
internalconstuintMASK=0x0fU;// the mask of 4 reserved bits
internalconstuintMAX=4;// maximum number of simultaneous ETW sessions supported

And we set them all to 1 by default in the manifest:

runtime/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs

Lines 3428 to 3439 in 01d1c8c

 metadata.Descriptor=newEventDescriptor(
eventAttribute.EventId,
eventAttribute.Version,
 #if FEATURE_MANAGED_ETW_CHANNELS
(byte)eventAttribute.Channel,
 #else 
(byte)0,
 #endif 
(byte)eventAttribute.Level,
(byte)eventAttribute.Opcode,
(int)eventAttribute.Task,
unchecked((long)((ulong)eventAttribute.Keywords|SessionMask.All.ToEventKeywords())));

This means that when we compute whether an event should be enabled we won't turn on EventSource events by default, since the event keywords are non-zero 0xF00000000000:

runtime/src/native/eventpipe/ep-provider.c

Line 152 in 01d1c8c

boolkeyword_enabled= (keywords==0) || ((session_keyword&keywords) !=0);

We have a workaround in the DiagnosticClient introduced here: dotnet/diagnostics#1091, but any other way of enabling EventPipe (env vars, other clients, etc) will still have this issue.

This fix lets the default EventSource keyword act as if it were 0 for all sessions.

This does have two compat issues

If someone has a provider that was using any of the masked bits it would now start to show up in traces that didn't have the keyword set
We cannot use those keywords for runtime events, our current high bit is 42 0x20000000000 so we are very close to that number. I don't think we have a choice regardless of this change though, due to EventSource treating those bits as reserved.

lateralusX

LGTM!

noahfalk · 2022-09-09T04:17:44Z

 int64_t session_keyword = ep_session_provider_get_keywords (session_provider);
 EventPipeEventLevel session_level = ep_session_provider_get_logging_level (session_provider);
+ // EventSources always set 0xF00000000000 to signify no keywords 
+ int64_t session_mask = ~0xF00000000000;


Rather than do this filtering at the point of use, how about we filter these keyword bits at the point we are initializing the event in provider_add_event?

noahfalk · 2022-09-09T04:28:28Z

We have a workaround in the DiagnosticClient introduced here: dotnet/diagnostics#1091

Rats, I missed when this change went in. I may be unaware of constraints Sung was under when he did that, but this change you have here looks like a much better approach.

noahfalk · 2022-09-09T04:31:30Z

If someone has a provider that was using any of the masked bits it would now start to show up in traces that didn't have the keyword set

If they did that they would already be seeing weird behavior under ETW. Its possible someone does it and never uses their EventSource with ETW, but the odds of that seem low enough that I am willing to risk inconveniencing them.

mikelle-rogers · 2022-09-28T16:37:39Z

Is there documentation that needs to be updated with this change?

davmason · 2022-09-30T11:16:56Z

@mikelle-rogers no documentation needed, this is making things work as already documented

davmason · 2022-10-01T10:40:13Z

I found out via failing tests that -1 as a keyword is special and we can't modify it, so I added that check

adamsitnik · 2022-10-04T10:48:18Z

@davmason are you going to backport this PR to 7 and 6?

davmason · 2022-10-11T08:37:03Z

@adamsitnik do you know of any customers that are asking for it? I'm happy to go through the process but the servicing bar requires a customer blocked on it

adamsitnik · 2022-10-11T12:10:52Z

@davmason From my perspective I wonder if this related to microsoft/perfview#1718

do you know of any customers that are asking for it?

@tmds ?

davmason · 2022-10-11T20:19:26Z

@davmason From my perspective I wonder if this related to microsoft/perfview#1718

Yes, that looks like the same issue. Trying to collect EventSources using the environment variables is broken. You can work around by either using dotnet-trace to collect instead, or setting keywords to 0xFFFFFFFF for any EventSources you want events from.

If we have people asking for the fix just point them to me and I can start the servicing process

adamsitnik · 2022-10-11T20:26:40Z

Yes, that looks like the same issue.
If we have people asking for the fix just point them to me and I can start the servicing process

Then this would be me as I want to publish a new BenchmarkDotNet version with the PerfCollectDiagnoser (dotnet/BenchmarkDotNet#2117). It's a plugin that does allow for profiling with perfcollect during the benchmarking (we already have sth like that for EventPipe, but it's missing the native call stack info which is often important).

I need the BDN events to be able to tell when given benchmark iteration started and finished to be able to implement detection of regression on top of it. This year I am aiming at adding a BDN feature where the user just specifies the benchmark that has regressed between .NET releases, BDN runs it with profiler attached, loads the trace file using Trace Event, filters it based on the events to selected time frame and then uses Trace Event to diff the traces and just tell the user where the regression is.

davmason · 2022-10-13T21:58:50Z

I'm happy to take it to servicing if that is the best outcome, but the next servicing date is in January so no fixes would be available until then. I suspect it will work better for you to find a workaround

Are you able to use the diagnostics client instead of the environment variables? https://learn.microsoft.com/en-us/dotnet/core/diagnostics/diagnostics-client-library

There is already a workaround in that library and you wouldn't have to wait on any servicing fixes, the client and runtime support attaching to your own process and attaching at startup, so it should work for most scenarios

…ords show up by default (dotnet#75248) Update ep-provider.c

…Pipe sessions (#75248) (#77811) * Update provider_compute_event_enable_mask so EventSouces with no keywords show up by default (#75248) Update ep-provider.c * Update ep-provider.c * Update src/native/eventpipe/ep-provider.c Co-authored-by: Juan Hoyos <juan.hoyos@microsoft.com> Co-authored-by: Juan Hoyos <juan.hoyos@microsoft.com>

davmason · 2022-09-08T08:52:24Z

Fixesdotnet/diagnostics#3298

EventSource uses bits 44-47 of the keywords to store data about sessions:

runtime/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs

Lines 5071 to 5073 in 01d1c8c

internalconstintSHIFT_SESSION_TO_KEYWORD=44;// bits 44-47 inclusive are reserved
internalconstuintMASK=0x0fU;// the mask of 4 reserved bits
internalconstuintMAX=4;// maximum number of simultaneous ETW sessions supported

And we set them all to 1 by default in the manifest:

runtime/src/libraries/System.Private.CoreLib/src/System/Diagnostics/Tracing/EventSource.cs

Lines 3428 to 3439 in 01d1c8c

 metadata.Descriptor=newEventDescriptor(
eventAttribute.EventId,
eventAttribute.Version,
 #if FEATURE_MANAGED_ETW_CHANNELS
(byte)eventAttribute.Channel,
 #else 
(byte)0,
 #endif 
(byte)eventAttribute.Level,
(byte)eventAttribute.Opcode,
(int)eventAttribute.Task,
unchecked((long)((ulong)eventAttribute.Keywords|SessionMask.All.ToEventKeywords())));

This means that when we compute whether an event should be enabled we won't turn on EventSource events by default, since the event keywords are non-zero 0xF00000000000:

runtime/src/native/eventpipe/ep-provider.c

Line 152 in 01d1c8c

boolkeyword_enabled= (keywords==0) || ((session_keyword&keywords) !=0);

We have a workaround in the DiagnosticClient introduced here: dotnet/diagnostics#1091, but any other way of enabling EventPipe (env vars, other clients, etc) will still have this issue.

This fix lets the default EventSource keyword act as if it were 0 for all sessions.

This does have two compat issues

If someone has a provider that was using any of the masked bits it would now start to show up in traces that didn't have the keyword set
We cannot use those keywords for runtime events, our current high bit is 42 0x20000000000 so we are very close to that number. I don't think we have a choice regardless of this change though, due to EventSource treating those bits as reserved.

lateralusX

LGTM!

noahfalk · 2022-09-09T04:17:44Z

 int64_t session_keyword = ep_session_provider_get_keywords (session_provider);
 EventPipeEventLevel session_level = ep_session_provider_get_logging_level (session_provider);
+ // EventSources always set 0xF00000000000 to signify no keywords 
+ int64_t session_mask = ~0xF00000000000;


Rather than do this filtering at the point of use, how about we filter these keyword bits at the point we are initializing the event in provider_add_event?

noahfalk · 2022-09-09T04:28:28Z

We have a workaround in the DiagnosticClient introduced here: dotnet/diagnostics#1091

Rats, I missed when this change went in. I may be unaware of constraints Sung was under when he did that, but this change you have here looks like a much better approach.

noahfalk · 2022-09-09T04:31:30Z

If someone has a provider that was using any of the masked bits it would now start to show up in traces that didn't have the keyword set

If they did that they would already be seeing weird behavior under ETW. Its possible someone does it and never uses their EventSource with ETW, but the odds of that seem low enough that I am willing to risk inconveniencing them.

mikelle-rogers · 2022-09-28T16:37:39Z

Is there documentation that needs to be updated with this change?

davmason · 2022-09-30T11:16:56Z

@mikelle-rogers no documentation needed, this is making things work as already documented

davmason · 2022-10-01T10:40:13Z

I found out via failing tests that -1 as a keyword is special and we can't modify it, so I added that check

adamsitnik · 2022-10-04T10:48:18Z

@davmason are you going to backport this PR to 7 and 6?

davmason · 2022-10-11T08:37:03Z

@adamsitnik do you know of any customers that are asking for it? I'm happy to go through the process but the servicing bar requires a customer blocked on it

adamsitnik · 2022-10-11T12:10:52Z

@davmason From my perspective I wonder if this related to microsoft/perfview#1718

do you know of any customers that are asking for it?

@tmds ?

davmason · 2022-10-11T20:19:26Z

@davmason From my perspective I wonder if this related to microsoft/perfview#1718

Yes, that looks like the same issue. Trying to collect EventSources using the environment variables is broken. You can work around by either using dotnet-trace to collect instead, or setting keywords to 0xFFFFFFFF for any EventSources you want events from.

If we have people asking for the fix just point them to me and I can start the servicing process

adamsitnik · 2022-10-11T20:26:40Z

Yes, that looks like the same issue.
If we have people asking for the fix just point them to me and I can start the servicing process

Then this would be me as I want to publish a new BenchmarkDotNet version with the PerfCollectDiagnoser (dotnet/BenchmarkDotNet#2117). It's a plugin that does allow for profiling with perfcollect during the benchmarking (we already have sth like that for EventPipe, but it's missing the native call stack info which is often important).

I need the BDN events to be able to tell when given benchmark iteration started and finished to be able to implement detection of regression on top of it. This year I am aiming at adding a BDN feature where the user just specifies the benchmark that has regressed between .NET releases, BDN runs it with profiler attached, loads the trace file using Trace Event, filters it based on the events to selected time frame and then uses Trace Event to diff the traces and just tell the user where the regression is.

davmason · 2022-10-13T21:58:50Z

I'm happy to take it to servicing if that is the best outcome, but the next servicing date is in January so no fixes would be available until then. I suspect it will work better for you to find a workaround

Are you able to use the diagnostics client instead of the environment variables? https://learn.microsoft.com/en-us/dotnet/core/diagnostics/diagnostics-client-library

There is already a workaround in that library and you wouldn't have to wait on any servicing fixes, the client and runtime support attaching to your own process and attaching at startup, so it should work for most scenarios

…ords show up by default (dotnet#75248) Update ep-provider.c

…Pipe sessions (#75248) (#77811) * Update provider_compute_event_enable_mask so EventSouces with no keywords show up by default (#75248) Update ep-provider.c * Update ep-provider.c * Update src/native/eventpipe/ep-provider.c Co-authored-by: Juan Hoyos <juan.hoyos@microsoft.com> Co-authored-by: Juan Hoyos <juan.hoyos@microsoft.com>

Update ep-provider.c
febfd88

davmason added the EventPipe label Sep 8, 2022

davmason added this to the 8.0.0 milestone Sep 8, 2022

davmason requested review from a team and lateralusX September 8, 2022 08:52

davmason self-assigned this Sep 8, 2022

ghost added the area-Tracing-coreclr label Sep 8, 2022

davmason mentioned this pull request Sep 8, 2022
Unable to set providers using EventPipeConfig dotnet/diagnostics#3298
Closed

lateralusX approved these changes Sep 8, 2022
View reviewed changes

noahfalk approved these changes Sep 9, 2022
View reviewed changes

Code review feedback
480eee9

runfoappBot mentioned this pull request Sep 21, 2022
Infra improvements for Helix #68176
Closed

davmason closed this Sep 30, 2022

davmason reopened this Sep 30, 2022

Don't change -1 as a keyword
d0a91c5

davmason force-pushed the eventsource_config branch from 1ee4973 to d0a91c5Compare October 1, 2022 10:33

davmason merged commit 28c7eb8 into dotnet:mainOct 4, 2022

davmason added a commit to davmason/runtime that referenced this pull request Nov 2, 2022
Update provider_compute_event_enable_mask so EventSouces with no keyw…
70aa756
…ords show up by default (dotnet#75248) Update ep-provider.c

davmason mentioned this pull request Nov 2, 2022
[release/7.0] Managed EventSources do not show up by default in EventPipe sessions (#75248) #77811
Merged

ghost locked as resolved and limited conversation to collaborators Nov 13, 2022

Update ep-provider.c
febfd88

davmason added the EventPipe label Sep 8, 2022

davmason added this to the 8.0.0 milestone Sep 8, 2022

davmason requested review from a team and lateralusX September 8, 2022 08:52

davmason self-assigned this Sep 8, 2022

ghost added the area-Tracing-coreclr label Sep 8, 2022

davmason mentioned this pull request Sep 8, 2022
Unable to set providers using EventPipeConfig dotnet/diagnostics#3298
Closed

lateralusX approved these changes Sep 8, 2022
View reviewed changes

noahfalk approved these changes Sep 9, 2022
View reviewed changes

Code review feedback
480eee9

runfoappBot mentioned this pull request Sep 21, 2022
Infra improvements for Helix #68176
Closed

davmason closed this Sep 30, 2022

davmason reopened this Sep 30, 2022

Don't change -1 as a keyword
d0a91c5

davmason force-pushed the eventsource_config branch from 1ee4973 to d0a91c5Compare October 1, 2022 10:33

davmason merged commit 28c7eb8 into dotnet:mainOct 4, 2022

davmason added a commit to davmason/runtime that referenced this pull request Nov 2, 2022
Update provider_compute_event_enable_mask so EventSouces with no keyw…
70aa756
…ords show up by default (dotnet#75248) Update ep-provider.c

davmason mentioned this pull request Nov 2, 2022
[release/7.0] Managed EventSources do not show up by default in EventPipe sessions (#75248) #77811
Merged

ghost locked as resolved and limited conversation to collaborators Nov 13, 2022

Update ep-provider.c
febfd88

davmason added the EventPipe label Sep 8, 2022

davmason added this to the 8.0.0 milestone Sep 8, 2022

davmason requested review from a team and lateralusX September 8, 2022 08:52

davmason self-assigned this Sep 8, 2022

ghost added the area-Tracing-coreclr label Sep 8, 2022

davmason mentioned this pull request Sep 8, 2022
Unable to set providers using EventPipeConfig dotnet/diagnostics#3298
Closed

lateralusX approved these changes Sep 8, 2022
View reviewed changes

noahfalk approved these changes Sep 9, 2022
View reviewed changes

Code review feedback
480eee9

runfoappBot mentioned this pull request Sep 21, 2022
Infra improvements for Helix #68176
Closed

davmason closed this Sep 30, 2022

davmason reopened this Sep 30, 2022

Don't change -1 as a keyword
d0a91c5

davmason force-pushed the eventsource_config branch from 1ee4973 to d0a91c5Compare October 1, 2022 10:33

davmason merged commit 28c7eb8 into dotnet:mainOct 4, 2022

davmason added a commit to davmason/runtime that referenced this pull request Nov 2, 2022
Update provider_compute_event_enable_mask so EventSouces with no keyw…
70aa756
…ords show up by default (dotnet#75248) Update ep-provider.c

davmason mentioned this pull request Nov 2, 2022
[release/7.0] Managed EventSources do not show up by default in EventPipe sessions (#75248) #77811
Merged

ghost locked as resolved and limited conversation to collaborators Nov 13, 2022

Update ep-provider.c
febfd88

davmason added the EventPipe label Sep 8, 2022

davmason added this to the 8.0.0 milestone Sep 8, 2022

davmason requested review from a team and lateralusX September 8, 2022 08:52

davmason self-assigned this Sep 8, 2022

ghost added the area-Tracing-coreclr label Sep 8, 2022

davmason mentioned this pull request Sep 8, 2022
Unable to set providers using EventPipeConfig dotnet/diagnostics#3298
Closed

lateralusX approved these changes Sep 8, 2022
View reviewed changes

noahfalk approved these changes Sep 9, 2022
View reviewed changes

Code review feedback
480eee9

runfoappBot mentioned this pull request Sep 21, 2022
Infra improvements for Helix #68176
Closed

davmason closed this Sep 30, 2022

davmason reopened this Sep 30, 2022

Don't change -1 as a keyword
d0a91c5

davmason force-pushed the eventsource_config branch from 1ee4973 to d0a91c5Compare October 1, 2022 10:33

davmason merged commit 28c7eb8 into dotnet:mainOct 4, 2022

davmason added a commit to davmason/runtime that referenced this pull request Nov 2, 2022
Update provider_compute_event_enable_mask so EventSouces with no keyw…
70aa756
…ords show up by default (dotnet#75248) Update ep-provider.c

davmason mentioned this pull request Nov 2, 2022
[release/7.0] Managed EventSources do not show up by default in EventPipe sessions (#75248) #77811
Merged

ghost locked as resolved and limited conversation to collaborators Nov 13, 2022

Update ep-provider.c
febfd88

davmason added the EventPipe label Sep 8, 2022

davmason added this to the 8.0.0 milestone Sep 8, 2022

davmason requested review from a team and lateralusX September 8, 2022 08:52

davmason self-assigned this Sep 8, 2022

ghost added the area-Tracing-coreclr label Sep 8, 2022

davmason mentioned this pull request Sep 8, 2022
Unable to set providers using EventPipeConfig dotnet/diagnostics#3298
Closed

lateralusX approved these changes Sep 8, 2022
View reviewed changes

noahfalk approved these changes Sep 9, 2022
View reviewed changes

Code review feedback
480eee9

runfoappBot mentioned this pull request Sep 21, 2022
Infra improvements for Helix #68176
Closed

davmason closed this Sep 30, 2022

davmason reopened this Sep 30, 2022

Don't change -1 as a keyword
d0a91c5

davmason force-pushed the eventsource_config branch from 1ee4973 to d0a91c5Compare October 1, 2022 10:33

davmason merged commit 28c7eb8 into dotnet:mainOct 4, 2022

davmason added a commit to davmason/runtime that referenced this pull request Nov 2, 2022
Update provider_compute_event_enable_mask so EventSouces with no keyw…
70aa756
…ords show up by default (dotnet#75248) Update ep-provider.c

davmason mentioned this pull request Nov 2, 2022
[release/7.0] Managed EventSources do not show up by default in EventPipe sessions (#75248) #77811
Merged

ghost locked as resolved and limited conversation to collaborators Nov 13, 2022

Update ep-provider.c
febfd88

davmason added the EventPipe label Sep 8, 2022

davmason added this to the 8.0.0 milestone Sep 8, 2022

davmason requested review from a team and lateralusX September 8, 2022 08:52

davmason self-assigned this Sep 8, 2022

ghost added the area-Tracing-coreclr label Sep 8, 2022

davmason mentioned this pull request Sep 8, 2022
Unable to set providers using EventPipeConfig dotnet/diagnostics#3298
Closed

lateralusX approved these changes Sep 8, 2022
View reviewed changes

noahfalk approved these changes Sep 9, 2022
View reviewed changes

Code review feedback
480eee9

runfoappBot mentioned this pull request Sep 21, 2022
Infra improvements for Helix #68176
Closed

davmason closed this Sep 30, 2022

davmason reopened this Sep 30, 2022

Don't change -1 as a keyword
d0a91c5

davmason force-pushed the eventsource_config branch from 1ee4973 to d0a91c5Compare October 1, 2022 10:33

davmason merged commit 28c7eb8 into dotnet:mainOct 4, 2022

davmason added a commit to davmason/runtime that referenced this pull request Nov 2, 2022
Update provider_compute_event_enable_mask so EventSouces with no keyw…
70aa756
…ords show up by default (dotnet#75248) Update ep-provider.c

davmason mentioned this pull request Nov 2, 2022
[release/7.0] Managed EventSources do not show up by default in EventPipe sessions (#75248) #77811
Merged

ghost locked as resolved and limited conversation to collaborators Nov 13, 2022

Update ep-provider.c
febfd88

davmason added the EventPipe label Sep 8, 2022

davmason added this to the 8.0.0 milestone Sep 8, 2022

davmason requested review from a team and lateralusX September 8, 2022 08:52

davmason self-assigned this Sep 8, 2022

ghost added the area-Tracing-coreclr label Sep 8, 2022

davmason mentioned this pull request Sep 8, 2022
Unable to set providers using EventPipeConfig dotnet/diagnostics#3298
Closed

lateralusX approved these changes Sep 8, 2022
View reviewed changes

noahfalk approved these changes Sep 9, 2022
View reviewed changes

Code review feedback
480eee9

runfoappBot mentioned this pull request Sep 21, 2022
Infra improvements for Helix #68176
Closed

davmason closed this Sep 30, 2022

davmason reopened this Sep 30, 2022

Don't change -1 as a keyword
d0a91c5

davmason force-pushed the eventsource_config branch from 1ee4973 to d0a91c5Compare October 1, 2022 10:33

davmason merged commit 28c7eb8 into dotnet:mainOct 4, 2022

davmason added a commit to davmason/runtime that referenced this pull request Nov 2, 2022
Update provider_compute_event_enable_mask so EventSouces with no keyw…
70aa756
…ords show up by default (dotnet#75248) Update ep-provider.c

davmason mentioned this pull request Nov 2, 2022
[release/7.0] Managed EventSources do not show up by default in EventPipe sessions (#75248) #77811
Merged

ghost locked as resolved and limited conversation to collaborators Nov 13, 2022

Update ep-provider.c
febfd88

davmason added the EventPipe label Sep 8, 2022

davmason added this to the 8.0.0 milestone Sep 8, 2022

davmason requested review from a team and lateralusX September 8, 2022 08:52

davmason self-assigned this Sep 8, 2022

ghost added the area-Tracing-coreclr label Sep 8, 2022

davmason mentioned this pull request Sep 8, 2022
Unable to set providers using EventPipeConfig dotnet/diagnostics#3298
Closed

lateralusX approved these changes Sep 8, 2022
View reviewed changes

noahfalk approved these changes Sep 9, 2022
View reviewed changes

Code review feedback
480eee9

runfoappBot mentioned this pull request Sep 21, 2022
Infra improvements for Helix #68176
Closed

davmason closed this Sep 30, 2022

davmason reopened this Sep 30, 2022

Don't change -1 as a keyword
d0a91c5

davmason force-pushed the eventsource_config branch from 1ee4973 to d0a91c5Compare October 1, 2022 10:33

davmason merged commit 28c7eb8 into dotnet:mainOct 4, 2022

davmason added a commit to davmason/runtime that referenced this pull request Nov 2, 2022
Update provider_compute_event_enable_mask so EventSouces with no keyw…
70aa756
…ords show up by default (dotnet#75248) Update ep-provider.c

davmason mentioned this pull request Nov 2, 2022
[release/7.0] Managed EventSources do not show up by default in EventPipe sessions (#75248) #77811
Merged

ghost locked as resolved and limited conversation to collaborators Nov 13, 2022

	internalconstintSHIFT_SESSION_TO_KEYWORD=44;// bits 44-47 inclusive are reserved
	internalconstuintMASK=0x0fU;// the mask of 4 reserved bits
	internalconstuintMAX=4;// maximum number of simultaneous ETW sessions supported

	metadata.Descriptor=newEventDescriptor(
	eventAttribute.EventId,
	eventAttribute.Version,
	#if FEATURE_MANAGED_ETW_CHANNELS
	(byte)eventAttribute.Channel,
	#else
	(byte)0,
	#endif
	(byte)eventAttribute.Level,
	(byte)eventAttribute.Opcode,
	(int)eventAttribute.Task,
	unchecked((long)((ulong)eventAttribute.Keywords\|SessionMask.All.ToEventKeywords())));

Uh oh!

Conversation

davmason commented Sep 8, 2022

Uh oh!

lateralusX left a comment

Choose a reason for hiding this comment

Uh oh!

noahfalkSep 9, 2022

Choose a reason for hiding this comment

Uh oh!

noahfalk commented Sep 9, 2022

Uh oh!

noahfalk commented Sep 9, 2022

Uh oh!

mikelle-rogers commented Sep 28, 2022

Uh oh!

davmason commented Sep 30, 2022

Uh oh!

davmason commented Oct 1, 2022

Uh oh!

adamsitnik commented Oct 4, 2022

Uh oh!

davmason commented Oct 11, 2022

Uh oh!

adamsitnik commented Oct 11, 2022

Uh oh!

davmason commented Oct 11, 2022

Uh oh!

adamsitnik commented Oct 11, 2022

Uh oh!

davmason commented Oct 13, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

davmason commented Sep 8, 2022

Uh oh!

lateralusX left a comment

Choose a reason for hiding this comment

Uh oh!

noahfalkSep 9, 2022

Choose a reason for hiding this comment

Uh oh!

noahfalk commented Sep 9, 2022

Uh oh!

noahfalk commented Sep 9, 2022

Uh oh!

mikelle-rogers commented Sep 28, 2022

Uh oh!

davmason commented Sep 30, 2022

Uh oh!

davmason commented Oct 1, 2022

Uh oh!

adamsitnik commented Oct 4, 2022

Uh oh!

davmason commented Oct 11, 2022

Uh oh!

adamsitnik commented Oct 11, 2022

Uh oh!

davmason commented Oct 11, 2022

Uh oh!

adamsitnik commented Oct 11, 2022

Uh oh!

davmason commented Oct 13, 2022

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants