Description
Currently EventPipe/DiagnosticServer shutdown won't clean up some resources, like default listeners IPC channel and won't stop diagnostic server thread, instead it relies on OS cleanup of resources on process exit. This works in the case where runtime lifetime == process lifetime, but in cases where runtime could be restarted (mono embedding scenarios), this will cause resource leaks, and potentially prevent the runtime to re-initialize.
https://github.com/dotnet/runtime/blob/main/src/native/eventpipe/ds-ipc-pal-namedpipe.c#L538
https://github.com/dotnet/runtime/blob/main/src/native/eventpipe/ds-ipc-pal-socket.c#L1303
Main reason why we can't close down the IPC channels during shutdown is because the shutdown does little efforts to orchestrate with threads currently using the IPC channels. The fix would include better orchestration between the diagnostic server thread that handles the IPC ports and the shutdown thread. Currently shutdown thread flags diagnostic server that a shutdown is in progress https://github.com/dotnet/runtime/blob/main/src/native/eventpipe/ds-server.c#L128, but if diagnostic server thread is blocked in ds_ipc_stream_factory_get_next_available_stream, shutdown thread wont wait and since there is no coordination around shared resource usage, shutdown can't close down the IPC ports.
There is also an old issue around EventPipe shutdown race condition, https://github.com/dotnet/runtime/blob/main/src/native/eventpipe/ep.c#L1456 that should be investigated in order to be able to free up even more resources during EventPipe shutdown.
Another thing that probably increase chances to hit runtime races is that we shutdown EventPipe before shutting down Diagnostic Server (https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/ceemain.cpp#L1138), it should probably be done in reverse order, making sure no new IPC channel requests comes in while shutting down EventPipe sessions and resources.