Causes the issue of multiple `explorer.exe` processes failing to exit automatically

[sonyps5201314]

#3760

Additionally, I noticed that you reverted ILSpy\Util\ShellHelper.cs. This unfortunately reintroduces the bug I previously fixed in 1f13b80.

The issue with multiple lingering explorer.exe processes has returned, and they are consuming a significant amount of user memory.

This issue hasn't been completely resolved either. Every time after a batch decompilation, clicking the 'Open Explorer' button still spawns a new explorer.exe process that fails to exit automatically.

[christophwille]

So we are talking about #3619?

Given that I am very hesitant to bring back large swaths of interop for a single platform, lets first define the feature you want: So "Open Explorer" does open a new explorer window. Why don't you simply close it?

[sonyps5201314]

The issue isn't with the window itself; the problem is that even after closing the window, the explorer.exe process still persists.

(This behavior doesn't happen on every system. For example, on my Win10 22H2 machine, the process exits automatically a few minutes after the window is closed. However, on my Win11 23H2 machine, the process remains alive indefinitely after closing the window, no matter how long I wait.)

[christophwille]

Process.Start(new ProcessStartInfo("explorer.exe", Quote(path)) { UseShellExecute = false });

That is what called underneath. However, this doesn't hold on to anything in terms of lifetime.

[sonyps5201314]

This is exactly the drawback of using Process.Start(new ProcessStartInfo("explorer.exe", Quote(path)) { UseShellExecute = false });. That is why I previously provided the COM invocation method to avoid this issue.

[christophwille]

https://devblogs.microsoft.com/dotnet/process-api-improvements-in-dotnet-11/ - I am very much inclined to wait until we get a better Process API (Process.StartAndForget)

[sonyps5201314]

That probably won't work. Isn't ILSpy already being compiled with the .NET 11 preview? You can easily test it right now to see if it actually makes a difference.

[christophwille]

We are not targeting STS (usually). Wait meant .NET 12.

[sonyps5201314]

Once an API is published, Microsoft's strict backward compatibility policy means its internal implementation and behavior won't change—even if you wait for .NET 12. The source code itself is only a few lines long, so you can easily review it yourself to predict whether it will work, or just write a quick C++ program calling ShellExecute, CreateProcess, the _exec family, or system to verify the behavior.

I am convinced this has absolutely nothing to do with unreleased handles. If that were the case, the latest versions of System Informer/Process Hacker wouldn't have prioritized the COM approach for their 'Open file location' / PhShellExploreFile features.

[christophwille]

We are not going to treat Windows preferentially if its implemenation is f*cked up. The Avalonia port happened so we as core team can leave Windows behind for our own machines.