Is it common to have multiple profilers attached to .net core 3.0 process at the same time

[Anna-Guseva]

I tried to attach profiler to the same .NET Core v3.0.0-preview6 process twice and suddenly I managed to do it. Is this expected case? .NET Framework versions don't allow such behavior.

Besides, I'm able to attach two performance profilers in sampling mode or memory + performance (sampling) profilers, but I get an error when try to attach two memory profilers.

[AaronRobinsonMSFT]

I tried to attach profiler to the same .NET Core v3.0.0-preview6 process twice and suddenly I managed to do it

@Anna-Guseva It would be helpful to elaborate on this statement. How was the attach performed? What profilers were being used? Are these ICorProfilerCallback implementations or some other profiler implementation? For example, the latest Visual Studio Profiler doesn't use an ICorProfilerCallback implementation but instead uses ETW to collect profiling data - the CLR in general has no limitations over non-ICorProfilerCallback profilers.

[Anna-Guseva]

@AaronRobinsonMSFT Both of our profilers implements ICorProfilerCallback interface. We can provide you the list of set event mask that we use in our profilers, would it be helpful for you?

[AaronRobinsonMSFT]

@Anna-Guseva Thanks. So these profilers that your team/company wrote. That is good to know. Are you following the attach process described at https://blogs.msdn.microsoft.com/davbr/2009/11/04/clr-v4-profiler-attach-basics-with-sample-code/? If so that is good to know. Based on my experience attach should only support a single ICorProfilerCallback instance unless an implementation provides a multi-plexing option. @noahfalk can comment more if .NET Core has provided additional functionality.

[Anna-Guseva]

@AaronRobinsonMSFT yes, we follow this guidelines. We also expected that only single ICorProfilerCallback allowed and it's true for .net framework, but not for coreclr.

[davmason]

Hi @Anna-Guseva, there is the Microsoft.IntrumentationEngine library that allows you to attach multiple profilers, but you should not be able to attach multiple profilers to the same process just using ICorProfiler.

Can you tell me more about how you are attaching the two profilers? Are you using the new attach mechanism via Microsoft.Diagnostics.Tools.RuntimeClient.DiagnosticsHelpers.AttachProfiler?

[Anna-Guseva]

@davmason we use attach mechanism via Microsoft.Diagnostics.Tools.RuntimeClient.DiagnosticsHelpers.AttachProfiler only.

[davmason]

Thanks for reporting this @Anna-Guseva. The check for whether a profiler is already present was missing from the new attach path. I will have a fix up for it soon.

[davmason]

This is fixed with dotnet/coreclr#25520. Thanks again for reporting it and let me know if you run in to any other issues.

[nadavye]

@davmason can you please share why you limit the implementation for a single profiler?
My team implements a profiler which uses the ICorProfilerCallback interface but we've hit a case in which one of our customers uses App Insights which they cannot remove.

I'm searching for a solution and wonder why it isn't supported.

[davmason]

@nadavye it isn't supported in the runtime because supporting multiple profilers at the same time causes certain issues. For example, what if both profilers want to inject instrumentation at the beginning of the same method? Only one can be truly at the beginning and the other would have to be after. There are various other issues along those lines.

There is a solution though, the Visual Studio team provides the CLRInstrumentationEngine Library that allows multiple profilers to be used at the same time. It is a shim that registers itself as the profiler, then multiple profilers can register with CLRInstrumentationEngine and coexist peacefully.

[nadavye]

@davmason thanks for the answer. Highly appreciated :)

Does it requires any changes from the profiler implementer or it should work with any known profile (Azure App Insights, New Relic, etc)?

[davmason]

@nadavye It is not something you can just drop in to multiplex profilers, you have to target it and it provides a different set of apis than the CLR ones. I am not an expert since it's maintained by another team, you probably will be best served by reading the documentation in the repo

[nadavye]

@davmason - already started to read the docs. Thanks for the detailed explanation. Highly appreciated :-)