Add a configuration option to disable the ability for ETW to rundown symbolic state

[mjsabby]

There can be times when an application does not want its symbolic data to be rundown through ETW or PerfMap out of process mechanisms.

This option would allow a .net core app to opt out of being rundown.

This is similar in spirit to https://github.com/dotnet/coreclr/issues/27134 which is a good setting for production apps that don't want debugging features.

[mjsabby]

cc @noahfalk

[noahfalk]

@mjsabby - can you give an example why a developer would set this proposed environment variable?

[mjsabby]

For example, if you're running in a production environment where you would not want an external tool to induce a rundown by turning on the ETW rundown provider. For large applications running down symbolic state causes noticeable pauses in program execution.

We are in such a situation where we actively defeat a service in our environment that tries to do this, but it'd be better if we could just be immune to it.

[noahfalk]

My initial impression is that the issue feels fairly niche? Would we have good reason to believe that when the tool uses a bad keyword we won't need another config var, and then when it uses a bad verbosity level we need another one, bad filter argument another one, and so on? As far as I am aware the Windows/ETW/profiler ecosystem to date has generally approached the problem as "If the profiler doesn't offer the performance you want, get the tool improved or don't use it." I'm sympathetic that this may not feel ideal from a user's standpoint, I'm just a bit worried that we are trying to fill a lake one pebble at a time if we are adding new configs each time we encounter one of the arbitrarily many ways a profiler can make an app run slow. It seems more efficient to fix the profiler at issue rather than add narrowly tailored guard-rails and get all the users to consider if they should be using each of them + all the tools have to consider how to respond when arbitrary subsets of features are unavailable.

[mjsabby]

The problem is in this case the tool is not something we control and runs as part of some overall system we use. It is niche, but it's reasonable too. It's basically an application saying we don't want an out of process mechanism to impact our services.

To me it's a simple change that would simplify our lives.

[noahfalk]

It's basically an application saying we don't want an out of process mechanism to impact our services.

What if a config disabled the runtime/EventSource interaction with ETW entirely? That feels like a much stronger and generic way for a service to say "don't impact me"

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

[dotnet-policy-service]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.