`Process.KillTree throws a lot of exceptions internally

[Youssef1313]

I'm seeing a situation in microsoft/testfx repo where Process.KillTree appears to take so long.

In the above case, the process itself has already exited before Kill(true) was called. Based on the code comment here:

runtime/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Win32.cs

Lines 378 to 380 in e8812e7

	// If the process has exited, the handle is invalid.
	if (handle.IsInvalid)
	return null;

I'm really surprised this condition isn't hit and we return immediately.
I guess it's not a supported scenario to kill whole tree if the parent process already exited?

Note: I haven't tried to create a minimal repro yet.

[Youssef1313]

Note that even if the process itself hasn't exited, something is still going on.

And seems somehow related to whether or not debugger is attached?

Run the following with debugger attached in VS:

using System.Diagnostics;

if (args.Length == 1 && args[0] == "1")
{
    var processStartInfo = new ProcessStartInfo(Process.GetCurrentProcess().MainModule!.FileName)
    {
        Arguments = "2",
        UseShellExecute = false,
        RedirectStandardOutput = true,
        RedirectStandardError = true,
    };

    Process.Start(processStartInfo);

    while (true)
    {
        Thread.Sleep(10000);
    }
}
else if (args.Length == 1 && args[0] == "2")
{
    while (true)
    {
        Thread.Sleep(10000);
    }
}

var processStartInfo1 = new ProcessStartInfo(Process.GetCurrentProcess().MainModule!.FileName)
{
    Arguments = "1",
    UseShellExecute = false,
    RedirectStandardOutput = true,
    RedirectStandardError = true,
};

var process = Process.Start(processStartInfo1);
Thread.Sleep(1000);
var timestamp = Stopwatch.GetTimestamp();
process.Kill(true);
Console.WriteLine(Stopwatch.GetElapsedTime(timestamp));

prints ~ 00:00:23.6890791

If I run without debugger, I get ~ 00:00:00.1698470.

23seconds seems like A LOT.

[Youssef1313]

Ping @dotnet/area-system-diagnostics-process. I hit this from time to time.

[jkotas]

Run the following with debugger attached in VS

I doubt there is much we can do about this in the .NET libraries. It is getting stuck in the OS.

[Youssef1313]

@jkotas Why is it very different when the debugger is attached though?

[jkotas]

My guess is that Windows has to coordinate the killing of the process between the debuggee and the debugger. The process cannot just disappear. There may be ways in VS debugger to make it better.

[Youssef1313]

My guess is that Windows has to coordinate the killing of the process between the debuggee and the debugger. The process cannot just disappear. There may be ways in VS debugger to make it better.

To the extent that it takes 23 seconds when debugger is attached and less than 0.2 seconds when it's not attached? 23 seconds feels to me extremely long and unreasonable.

This is currently slowing me down a lot when debugging our integration tests in microsoft/testfx repo.

[jkotas]

Changing area to diagnostics-coreclr. It is a debugger issue, not a System.Diagnostics.Process issue.

[hoyosjs]

I can't seem to repro this - I consistently get sub-second times debugging or not.