mirror of
https://github.com/ElectronNET/Electron.NET.git
synced 2026-02-03 21:25:13 +00:00
Hanging Electron process after running tests #1026
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @agracio on GitHub (Dec 6, 2025).
This is likely related to the issue that we get 3 idle processes if .NET side throws an exception, but slightly different.
I have a hanging electron.exe process for each integration test run, is there something we can do about them?
@softworkz commented on GitHub (Dec 6, 2025):
How does it happen? Any tests failing? Do you debug the tests? Or do you stop them at some point?
@agracio commented on GitHub (Dec 6, 2025):
This happens when I use Resharper test runner in IDE - not sure if you have Resharper installed in your VS instance, when tests are running from
dotnet testthe 4 instances that get created during the run do close correctly.Probably a Resharper runner issue.
As for the 3 idle processes that are left hanging when .net encounters exception it is very easy to reproduce - open demo app and try using Auto Update. There is an unhandled null reference exception in that code that crashes .net side of Electron.NET resulting in Socket disconnect. This means that closing the app does not close 3 Electron instances running in the background.
@softworkz commented on GitHub (Dec 6, 2025):
I always use the VS test integration (even though I have R# installed).
You may perhapt need to disable parallel test exection for R#...?
That's an issue in the demo app, not in Electron.NET. An unhandled exception is an application bug.
@agracio commented on GitHub (Dec 6, 2025):
Yes and no, it just demonstrates that any unhandled exception can disconnect Electron.NET from the backend and it is not visible to the end user since the application does remain responsive to some interactions that do not go to backend.
@agracio commented on GitHub (Dec 6, 2025):
As for R# there does not appear to be a way to disable parallel running, so I will treat it as R# bug/feature.
@softworkz commented on GitHub (Dec 6, 2025):
When you develop a .net application, then it is your responsibility to make sure that no unhandled exception happen. Any librararies you use have nothing to do with that.
@softworkz commented on GitHub (Dec 6, 2025):
For such reasons, in earlier .net versions, applications always exited when there was an unhandled exception. It was changed later for other reasons (there are good reasons for either), but what hasn't changed is that normally, an unhandled exception means that the application state has become invalid.
@agracio commented on GitHub (Dec 6, 2025):
Of course you need to handle exceptions properly in your applications, the only issue I see is that in this case it leaves 3 orphan electron processes every time it fails.
It is not a huge deal but maybe there is a way to do something about it.
Anyway since the original issue turned out to be R# I will close it.
@softworkz commented on GitHub (Dec 6, 2025):
Sure - you can start swallowing exceptions - but this way, your aren't doing any favor to the application developer, because they might never get to know about certain problems in their app, then.
@agracio commented on GitHub (Dec 6, 2025):
That is not what I meant, when there is a .net exception and front end of Electron.NET disconnects from backend there are 3 orphaned electron.exe processes that are left behind.
Closing Electron.NET app leaves them just hanging, with another 3 spawned when you open another instance of Electron.NET app.
@softworkz commented on GitHub (Dec 6, 2025):
What exactly do you mean by frontend and backend?
@agracio commented on GitHub (Dec 6, 2025):
There is a .net frontend or your UI for that matter that is visible to the user it runs Sockets to connect to the underlying electron.exe with Typescript implementation which is what I would call a backend. That electron.exe is where you send all of your Socket commands to and and expect response.
When you close your app you send a command using Sockets to close electron.exe that is listening to your requests.
In case of .net exception it completely disconnects the two and the underlying electron.exe will continue listening to requests on whatever port it has launched, it will never close. The underlying Electron process spawns 3 electron.exe instances which is very common with Electron and those instances will be hanging indefinitely when .net part closes abruptly.
@softworkz commented on GitHub (Dec 6, 2025):
I'll try to respond tomorrow. Can't type that much anymore and dinner is 1 min away :-)