Why does my Unity 6000 + C# game build (for Win11) remain in memory when I close it by pressing Alt+F4. There are no error messages. The game disappears from the screen, but the process itself is visible in the task manager. What could be the reasons? In what directions should I look? (I tried to connect remote debug to the BC and looked at the logs, everything is clean)
Returned the project to Unity 2022, everything became normal. The reason in Unity 6000 is unclear.
It seems like some aspect of the process is refusing to shut down. If you can make a small project that reproduces the issue, please file a bug and we can take a look into what is going on.
Thanks!
Hi Phil_Z! There minimal project (no scripts) - TestUnclosable00.zip - Google Drive
(6000.0.32f1)
Stay in memory. Some packages removed, like AI_pathfinding, Rider …
Notes on behavior:
- I see the same behavior when closing via Alt+F4 / Close button - process remains in memory.
- The process does exit memory when calling
Application.Quit
directly (see note below), which we do in theApplication.wantsToQuit
handler after saving game state. - Returning
true
in all cases fromApplication.wantsToQuit
leaves the process in memory.
… | … |
---|---|
Version | 6000.0.29f1 |
Built on | windows 11 |
Tested on | windows 11 |
A non-desirable workaround / behavior notes:
Within
Application.wantsToQuit
handler, returnfalse
and set alternate flag that the application should exit. Detect and act on the flag (Application.Quit
) in a subsequentUpdate
. The application will exit. CallingApplication.Quit directly in the
wantsToQuit` handler does not cause application to exit.
Tested on Win10, all normal, process exit successfully. (build on win10/11 also)
But assembled on win10, buggy on win11.
I filed an incident with QA, and they will take the info and send it to the right team. Thanks for reporting this!
Hey!
I’m curious of your workaround.
I tried this following your instructions, which just prevents the build from being closed all together. What am I doing wrong?
using UnityEngine;
public class QuitHandler : MonoBehaviour
{
private static bool shouldQuit = false;
[RuntimeInitializeOnLoadMethod]
static void OnRuntimeMethodLoad()
{
Application.wantsToQuit += HandleWantsToQuit;
}
private static bool HandleWantsToQuit()
{
shouldQuit = true;
return false; // Prevent quitting immediately
}
void Update()
{
if (shouldQuit)
{
Debug.Log("Quitting application...");
Application.Quit();
}
}
}
EDIT:
Nevermind, this solution worked for me:
Good that you found another workaround, though it is a bit brutal. I wonder if there is some shutdown/saving piece that gets bypassed.
Fwiw, the piece to add to what you posted is below. The Application.Quit()
from your Update
generates another callback to the handler. Return true
this time causes a normal exit in our code for some unknown reason. Hopefully this is all moot by now and there’s a proper fix in the general release.
private static bool HandleWantsToQuit()
{
// Application.Quit from your Update() will generate another call into
// this quit handler. Returning true this time around causes a normal exit.
if (shouldQuit)
return true;
shouldQuit = true;
return false; // Prevent quitting immediately
}
I have this problem in my current game and use a nasty workaround to fix it. Interestingly, on my PC, it only occurs for me if the new Input system (or both) are enabled, but not when only using the old one. It really needs to be fixed.
We are working on a fix and hope to have it available soon.