dotnet-counters: Missing System.Runtime-Counters when publishing a trimmed app

[clane2812]

Description

When a net6-application is published 'trimmed', the System.Runtime-Counters collected with dotnet-counters are not available.

Reproduction Steps

• Create and run a simple console-application

• dotnet-counters monitor --process-id --refresh-interval 3 --counters System.Runtime

• All counters are collected

• Publish the app with 'trimmed' mode and run it

• dotnet-counters monitor --process-id --refresh-interval 3 --counters System.Runtime

• No counters are collected

The behaviour is described in the (closed) issue #44910 as well.

Expected behavior

System.Runtime counters give essential first-level informations when you search for example memory-leaks in a running docker-container. I would expect to get these important informations independent of the publish-mode.

Actual behavior

A docker-container which is published trimmed cannot be profiled with dotnet-counters (concerning the System.Runtime-Counters)

Regression?

No response

Known Workarounds

The workaround described in #44910 works: if you manually initialize the event-source, the counters are available in the trimmed container-image as well:

var corelib = typeof(EventSource).Assembly;
var runtimeEventSource = corelib.GetType("System.Diagnostics.Tracing.RuntimeEventSource");
var initialize = runtimeEventSource.GetMethod("Initialize");
initialize.Invoke(null, null);

I run the above snippet in the startup of the app, depending of an env-var, so you can turn on/off the profiling in a container

Configuration

No response

Other information

No response

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

When a net6-application is published 'trimmed', the System.Runtime-Counters collected with dotnet-counters are not available.

Reproduction Steps

• Create and run a simple console-application

• dotnet-counters monitor --process-id --refresh-interval 3 --counters System.Runtime

• All counters are collected

• Publish the app with 'trimmed' mode and run it

• dotnet-counters monitor --process-id --refresh-interval 3 --counters System.Runtime

• No counters are collected

The behaviour is described in the (closed) issue #44910 as well.

Expected behavior

System.Runtime counters give essential first-level informations when you search for example memory-leaks in a running docker-container. I would expect to get these important informations independent of the publish-mode.

Actual behavior

A docker-container which is published trimmed cannot be profiled with dotnet-counters (concerning the System.Runtime-Counters)

Regression?

No response

Known Workarounds

The workaround described in #44910 works: if you manually initialize the event-source, the counters are available in the trimmed container-image as well:

var corelib = typeof(EventSource).Assembly;
var runtimeEventSource = corelib.GetType("System.Diagnostics.Tracing.RuntimeEventSource");
var initialize = runtimeEventSource.GetMethod("Initialize");
initialize.Invoke(null, null);

I run the above snippet in the startup of the app, depending of an env-var, so you can turn on/off the profiling in a container

Configuration

No response

Other information

No response

Author:	clane2812
Assignees:	-
Labels:	area-Diagnostics-coreclr, untriaged
Milestone:	-

[tommcdon]

@clane2812 Thanks for reporting this issue! Does this issue reproduce on .net 7?
cc @LakshanF @eerhardt

[clane2812]

@tommcdon - yes, the issue is the same with .net7. Tried debug/release publish as well, but this makes no difference:
publish trimmed -> no counters available
publish normal -> all counters available

[tommcdon]

@LakshanF @eerhardt @tarekgh please take a look

[davmason]

@LakshanF, would we be able to get EventSource whitelisted so it is not trimmed? I am not sure what our policy is around that. It would be great if we could support diagnostic scenarios like counters out of the box instead of having users debug/fix it on their own.

[MichalStrehovsky]

@davmason what is the thing that is getting trimmed here and shouldn't?

I see there's descriptors that say not to trim the Initialize method mentioned in this issue:

runtime/src/libraries/System.Private.CoreLib/src/ILLink/ILLink.Descriptors.EventSource.xml

Line 4 in da2c147

<method signature="System.Void Initialize()" />

What else is needed?

[davmason]

Sorry for the delay here, we have had an influx of issues. I have asked @dramos020 to take a look

[dramos020]

After some investigation, I believe that it is not Initialize() that is getting trimmed, but instead ProcessStartupHooks(), which calls Initialize(), that is getting trimmed. It seems that the trimming is happening because StartupHookSupport is disabled by default. Not sure what the solution/next steps to this would be.

[jkotas]

This was fixed for .NET 8 by #80391