Running console application that creates and joins with short-lived threads leaks handles when debugger is attached

[dev991301]

Description

When the debugger is attached to an application that repeatedly creates and joins with short-lived threads, performance monitor shows the handles associated with the application growing linearly. The growth was observed when run with the debugger in Visual Studio Code, Visual Studio and JetBrains Rider.

When the same application is run via "dotnet run" from a terminal, the handle count is stable.

Reproduction Steps

while (true)
{
    var thread = new Thread(() => Thread.Sleep(1_000));
    thread.Start();
    thread.Join();
    GC.Collect();
    GC.WaitForPendingFinalizers();
    Console.WriteLine($"{DateTime.Now} iterate");
}

Expected behavior

It is expected that performance monitor would show the handle count as stable like it shows when run via "dotnet run". Below is a screenshot of what performance monitor shows when running the application under "dotnet run".

Actual behavior

Below is a screenshot of what performance monitor shows when run with the debugger in Visual Studio Code. The same growth is observed when run with the debugger attached in Visual Studio and JetBrains Rider.

Regression?

The application running under the debugger shows the growth in the handles in .NET 8 and .NET Framework 4.8.

Known Workarounds

No response

Configuration

.NET 8 and .NET Framework 4.8 Windows 11 x64

Other information

When the application is run under WinDbg, it does not show growth in the handles. So possibly it is in the managed debugging code.

[dotnet-policy-service[bot]]

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

[tommcdon]

Hello @dev991301! Thanks for reporting this issue! Is this issue blocking or causing a negative impact to the development environment, or is this more of an observation but isn't causing any issues?

[dev991301]

This issue isn't currently blocking my work.

I was debugging a crash that only happens after my application runs for long periods of time when I noticed a handle leak.

I spent a long time trying to figure out if my application also had a handle leak or if the leak was related to the crash. Once I figured out it was just a side effect of running it in the debugger, I decided to create this issue so anyone else noticing the problem could find this report.

[tommcdon]

Thanks @dev991301! To clarify the location of the handle leak - is the handle leak machine-wide, or specific to a process? Based off the description it sounds like the app is leaking handles, but it would be good to verify - when debugging, the debugger (e.g. Visual Studio) and the target app it is debugging both are tracking threads. I am curious if the handle leak is specific to the app, debugger, or something else.