Don't shut down event pipe in DLLs on Windows

[MichalStrehovsky]

Works around #89346.

We blocked event pipe completely in shared libraries in #90811 but:

• Elinor found out the shutdown problem is actually Windows specific, so blocking Linux (our most important target) is unnecessary.
• We can avoid the hang at the cost of corrupting the ongoing event pipe session by just not doing the shutdown. This can be worked around by simply stopping the event pipe session at dotnet-trace side manually.

I validated the shared library scenario no longer hangs at shutdown with this.

#89346 still tracks if we can do better here.

Cc @dotnet/ilc-contrib

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Works around #89346.

We blocked event pipe completely in shared libraries in #90811 but:

• Elinor found out the shutdown problem is actually Windows specific, so blocking Linux (our most important target) is unnecessary.
• We can avoid the hang at the cost of corrupting the ongoing event pipe session by just not doing the shutdown. This can be worked around by simply stopping the event pipe session at dotnet-trace side manually.

I validated the shared library scenario no longer hangs at shutdown with this.

#89346 still tracks if we can do better here.

Cc @dotnet/ilc-contrib

Author:	MichalStrehovsky
Assignees:	-
Labels:	area-NativeAOT-coreclr
Milestone:	-

[LakshanF]

LGTM, Thanks!

[agocke]

Does it actually work though? Can you load two libraries into the same process, enable event support, and the use dotnet-monitor or similar to retrieve events from both libraries?

I'd rather disable this completely until we're confident the scenario is working as we want it to.

[elinor-fung]

I'd rather disable this completely until we're confident the scenario is working as we want it to.

What about allowing a bypass? So blocked by default because of the multiple runtime questions, but still let people explicitly enable it as a 'I understand the limitations - I will only have one library/runtime and I want to be able to trace it'. I think that was actually @MichalStrehovsky's original suggestion.

[agocke]

Yup, bypass sounds great, just like we did with WPF.

[MichalStrehovsky]

This is what I had in mind if we really insist on blocking this.

This is different from the WPF block because that one doesn't work at all. This works, for a large majority of users.

[agocke]

This works, for a large majority of users.

That's what I was asking, though. Does it? Loading two CoreCLR instances in the same process is unsupported. Loading two Native AOT binaries in the same process is fully supported.

If this is fully supported, I would expect it to be fully supported across all our supported configurations.

[MichalStrehovsky]

That's what I was asking, though. Does it? Loading two CoreCLR instances in the same process is unsupported. Loading two Native AOT binaries in the same process is fully supported.

Yes, but so is EventSourceSupport in Native AOT exe files, and CoreCLR hosting APIs. Still if you use all of these in a single process, it will likely hit the same issue as two NativeAOT dlls. I think the right course of action is not in blocking (because we can't block that one), but in defining a failure mode.

[MichalStrehovsky]

@agcoke the last commit downgrades the error to a suppressible warning with a link to the issue. I considered making a fwlink for it but maybe that's an overkill.

[agocke]

LGTM, minor wording change suggested, and replaced link with a link to our official docs. I figure we can add a line in here to fully explain the situation.

[MichalStrehovsky]

/backport to release/8.0

[github-actions]

Started backporting to release/8.0: https://github.com/dotnet/runtime/actions/runs/6181325936