Godot will not startup from project manager if the default terminal application is set to Windows Terminal in Windows 11

[Xwdit]

---

Bugsquad note: This issue has been confirmed several times already. No need to confirm it further.

---

Godot version

4.0.dev(fad7034)

System information

Windows 11

Issue description

Godot will not startup from project manager if set the default terminal software to Windows Terminal in Windows 11, it will close immediately

Steps to reproduce

1. Change the default terminal application from cmd to Windows Terminal in Windows Terminal Settings.
2. Try to open a project in Godot's project manager
3. Godot window close immediately like a crash

Minimal reproduction project

No response

[Calinou]

This is likely because the Godot editor uses the console subsystem for editor builds.

As a workaround, compile Godot with windows_subsystem=gui on the SCons command line. This will disable the console entirely (which means you won't be able to toggle it back on).

[Anutrix]

I am on Windows 11 Pro 21H2 and not able to reproduce this.
Works fine for me.

Update:

• Works fine when started from Windows Terminal.

• Works fine when started from cmd.exe.

• Works fine when started from VSCode's Windows Terminal.

• Doesn't work when started from VSCode debug launch options.
  Note that this also open's an extra black empty window of 0x0 size of Microsoft.WindowsTerminal_1.11.2921.0_x64__8wekyb3d8bbwe\OpenConsole.exe. Closing it has no effect.

Update 2:

• In launch.json, "console": "internalConsole" causes crash but "console": "integratedTerminal" does not.

Seems like a Windows/Windows Terminal/VSCode(vscppdbg) bug, rather than Godot.

[cybereality]

I am able to reproduce this consistently on 2 machines with Windows 11. The setting that messes it up is this:

---

While "Windows Console Host" is the default, if you change the "Default terminal application" to "Windows Terminal" (which Microsoft prompts you to do, so may be a common issue). Then Godot immediately closes once opening a project. Note, this happens even on the latest stable build 3.3.4 as well.

Interestingly, it only happens when opening Godot by double-clicking the exe in the file explorer, or by clicking a shortcut (for example, if you have an icon on your taskbar, which I imagine is common for Windows users). If you manually open a command prompt or the Windows Terminal, and launch Godot from there, then it works fine.

If I had to guess, Godot isn't crashing. Maybe the default behavior of the Windows Terminal closes early (when whatever Godot does to switch from project manager mode to editor mode) and it is the terminal closure that is causing Godot to exit (which is why it works fine with a manually opened terminal).

[MarioLiebisch]

Just wanted to mention that while I can observe the very same issue on the 3.4 stable (Steam install) I don't get the issue with latest 4.0 compiled from scratch, using the Terminal Preview from Microsoft Store. I actually don't remember 4.0 ever showing this behavior since switching to Windows 11 (and Terminal Preview as the default) a month ago.

However, there's a different thing going on:
When I open 4.0 from Explorer, I'll get a terminal window and the Project Manager (as expected). Now if I open a project, the project opens fine, but the terminal window will close, showing no console output for the editor (the setting to hide the console window is off).

[robpc]

I have this issue and changing the setting back to Windows Console Host fixes it. The odd thing is that I have has Windows Terminal set as the default for a year-ish but this issue only came up in the last few days. I also have this issue with 3.3.2, 3.3.3 and 3.3.4, as well as 3.4.

[MarioLiebisch]

The odd thing is that I have has Windows Terminal set as the default for a year-ish but this issue only came up in the last few days.
Think you're confusing something here. As far as I know, this functionality is rather new (it arrived in the Terminal's stable branch just recently (after Windows 11's launch). Before it was in the preview branch for a month or two I think.

[robpc]

Think you're confusing something here. As far as I know, this functionality is rather new (it arrived in the Terminal's stable branch just recently (after Windows 11's launch). Before it was in the preview branch for a month or two I think.

Ahh, perhaps. I have been using it as my default terminal for a long time so maybe that was an assumption about the setting. On the other hand, I haven't touched the settings in months. Was an update for that pushed out in the last three days that turned it on by default? (I would believe it lol).

EDIT: I see it in these release notes for my version from 10/21/2021 so I suppose that's it. https://github.com/microsoft/terminal/releases/tag/v1.11.2921.0 I was pretty sure I was using Godot after that, but but maybe I got the update late.

[MarioLiebisch]

Windows Terminal (the non-preview version) was updated on 28th October for me. I think it's the first non-preview version actually supporting to become the system default.

[robpc]

Mine was modified 10/31. Probably been broken since then... that seems likely based on my recent Godot usage (ironically seems to be last used on the 31st).

[Fr0sk]

If I run it as an admin it seems to work fine. So, as a quick(er) workaround, you could check "Run this program as an administrator" and keep the Windows Terminal as the default terminal.

[Netito77]

If I run it as an admin it seems to work fine. So, as a quick(er) workaround, you could check "Run this program as an administrator" and keep the Windows Terminal as the default terminal.

I tried to run as an administrator, but the program ended up closing anyway. No results. :\

[marekadamczyk]

If anyone would still like to use the Windows Terminal below batch script is working as a workaround till version 4.0 will be released:

@echo off
taskkill /im openconsole.exe > NUL
Godot_v3.4-stable_win64.exe
set /p GODOT=

[Listwon]

I don't have much time to experiment right now, but one thing that is worth testing, would be to use CreateProcessW() instead of _wpopen() in OS_Windows::execute(). Because there are some caveats of using _wpopen as we can read in the documentation
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/popen-wpopen?view=msvc-170
https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw

Edit: Sorry, I missed it. It is already there.

I confirm the issue on my side too. Windows Terminal set as default terminal application. If I start the Godot binary from the Terminal itself, it opens projects properly.

[n3rdw1z4rd]

When I try to use that compile option, I get the following:

$ scons -j16 platform=windows target=release_debug windows_subsystem=gui
scons: Reading SConscript files ...
WARNING: Unknown SCons variables were passed and will be ignored:
windows_subsystem=gui
Configuring for Windows: target=release_debug, bits=default
Found MSVC version 14.2, arch amd64, bits=64
Checking for C header file mntent.h... (cached) no
scons: done reading SConscript files.
scons: Building targets ...

[MarioLiebisch]

one thing that is worth testing, would be to use CreateProcessW() instead of _wpopen() in OS_Windows::execute().

Had a bit of time earlier today, so removed the whole section using _wpopen() and added the pipe handling to the CreateProcessW() section, but it's still failing/exiting (with stdout being properly redirected), so it's most likely not the function call or it's something related to the pipes themselves. Or I made some mistake, but it's closing properly without any issues or crashing.

Godot Engine v4.0.dev.custom_build.8f0c6ce72 - https://godotengine.org
Vulkan API 1.2.189 - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 1080

Editing project: Project/Path (Project::Path)
Godot Engine v4.0.dev.custom_build.8f0c6ce72 - https://godotengine.org
Vulkan API 1.2.189 - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 1080

[Verarbeitung des Prozesses mit Code 0 (0x00000000) beendet]

[malachite23]

I hava found a solution, add CREATE_NEW_CONSOLE flag to here

Here's a Microsoft document that explains the problem:
Creation of a console

Please note this sentence in parentheses:

By default, a console process inherits its parent's console, and there is no guarantee that input is received by the process for which it was intended.

The reason for the issue is obvious, the editor process created by the project manager inherits the console of project manager, but the consle process exited after the project manager was quited, so the editor process was closed along with the consle process.

[bruvzg]

I hava found a solution, add CREATE_NEW_CONSOLE flag to here

Or add DETACHED_PROCESS, but neither is a good solution, CREATE_NEW_CONSOLE will open a new console window for every started process (including tools used during the export and running on the background, like adb), and DETACHED_PROCESS will disable console for the editor.

Probably the best we can do is to force windows_subsystem=gui and open a new console for the editor instances only, using AllocConsole.

but the consle process exited after the project manager was quited, so the editor process was closed along with the consle process.

Exiting project manager is the reason, but it should not happen, it's a new terminal bug. The console should stay opened until the last attached process is terminated.

https://docs.microsoft.com/en-us/windows/console/closing-a-console

... If other processes share the console, the console is not destroyed, ...
... A console is closed when the last process attached to it terminates or calls FreeConsole.

[mhilbrunner]

Exiting project manager is the reason, but it should not happen, it's a new terminal bug. The console should stay opened until the last attached process is terminated.

Seems they changed that in Windows Terminal, it only tracks the first attached process and exits once that exits:
microsoft/terminal#10501

[trevorwinser]

Has anyone found a stable solution for this via the terminal?

[MarioLiebisch]

Whatever your issue is, I don't think this is related. This issue has been fixed long time ago (and I even forgot it existed).

[Pjdn98]

Estou tendo esse tipo de problema no Godot 4