(Win11) Why does my Unity 6000 + C# game build remain in memory when I close it by pressing Alt+F4?

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)

2 Likes

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:

  1. I see the same behavior when closing via Alt+F4 / Close button - process remains in memory.
  2. The process does exit memory when calling Application.Quit directly (see note below), which we do in the Application.wantsToQuit handler after saving game state.
  3. Returning true in all cases from Application.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, return false and set alternate flag that the application should exit. Detect and act on the flag (Application.Quit) in a subsequent Update. The application will exit. Calling Application.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! :slightly_smiling_face:

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.

2 Likes

We are working on a fix and hope to have it available soon.