.Net / Windows / Main Branch: Editor Sometimes Crashes in Random Spot non-dev build

[Delsin-Yu]

Tested versions

Godot v4.3.dev.mono (fe01776)

System information

Godot v4.3.dev.mono (fe01776) - Windows 10.0.17763 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4060 Ti (NVIDIA; 31.0.15.4601) - AMD Ryzen 9 5900X 12-Core Processor (24 Threads)

Issue description

For mono + non-dev builds, Godot Editor sometimes may crash on startup, furthermore debugging breaks at this line:

Clicking the Continue button will show the program paused on exception, which is

The error code is STATUS_HEAP_CORRUPTION (A heap has been corrupted.).

Steps to reproduce

I am not sure if this is an OS-specific issue, but the repro is here:

1. Clone the commit fe01776f0.
2. Build the source with the mono module and debug symbols enabled according to the documentation.
3. Launch the editor, select and open a project.
4. Inspect the issue happens sometimes.

Minimal reproduction project (MRP)

N/A

Maybe fixed by
#89861

[viksl]

I can confirm this on windows 11 with latest master too.
it has been happening for about a week or so. The project selection works fine but when trying to open the project it starts opening it, loading something then crashes without loading the editor properly (no matter if it's a new project or an olde one), although at some rare moments (I don't know why, planets aligned or something?) I get into the editor and crash a bit later but that's like 1% of tries.

[Delsin-Yu]

A short video.

QQ2024320-173719.mp4

[Delsin-Yu]

In my second build it starts crashing at another line....
Now it is saying access violation.

[zaevi]

Can confirm. And it doesn't happen with dev_build enabled.

I removed the code to load certificates at main.cpp, then the crash happened elsewhere.

[Delsin-Yu]

@AThousandShips request platform:windows tag

[viksl]

I went through the history building and this is the first where it breaks for me: 77f6e35. The one before: 8bfc257 works for me just fine.
I hope I did it alright, first time trying this in this IDE but so far that's it from my side.
(by just fine I mean I can launch a project into editor, I haven't spent more time in it so don't know if it would crash at some point later while working with the editor)

Is it the same on your side?

EDIT:
Also I take back the comment about debug_symbols making it work, it still crashes on me unless I also enable the dev_build.
This should probably also have the regression label.

[Delsin-Yu]

I went through the history building and this is the first where it breaks for me: 77f6e35. The one before: 8bfc257 works for me just fine. I hope I did it alright, first time trying this in this IDE but so far that's it from my side. (by just fine I mean I can launch a project into editor, I haven't spent more time in it so don't know if it would crash at some point later while working with the editor)

Is it the same on your side?

EDIT: Also I take back the comment about debug_symbols making it work, it still crashes on me unless I also enable the dev_build. This should probably also have the regression label.

I'm doing a range of building/testing, I even went to the commits on March 10, which led me to believe there are some problems on my end, at least on mono build.

[Delsin-Yu]

I made 4 builds, and tests them by opening an empty project individually:

• [OK] Dev5 [89f70e9]
• [OK] Dev5 Mono [89f70e9]
• [OK] Main [fe01776]
• [Crash!] Main Mono [fe01776]

That narrows the scope of the issue:

[bruvzg]

[Crash!] Main Mono [https://github.com/godotengine/godot/commit/fe01776f05b1787b28b4a270d53037a3c25f4ca2]

Windows 10.0.17763

The only relevant part is probably dark mode detection (Windows build number checks might be off), 17763 seems to be outdated Windows 10 version from 2018 (current supported versions are 19044/19045), so no idea how to test it.

If you are really using this version of Windows, try commenting function calls here one-by-one, to narrow it down.

godot/platform/windows/display_server_windows.cpp

Lines 5512 to 5523 in fe01776

	bool dark_mode = ShouldAppsUseDarkMode();
	if (SetPreferredAppMode) {
	SetPreferredAppMode(dark_mode ? APPMODE_ALLOWDARK : APPMODE_DEFAULT);
	} else if (AllowDarkModeForApp) {
	AllowDarkModeForApp(dark_mode);
	}
	if (RefreshImmersiveColorPolicyState) {
	RefreshImmersiveColorPolicyState();
	}
	if (FlushMenuThemes) {
	FlushMenuThemes();
	}

But I'm not sure how it's related to Mono.

[Delsin-Yu]

[Crash!] Main Mono [https://github.com/godotengine/godot/commit/fe01776f05b1787b28b4a270d53037a3c25f4ca2]

Windows 10.0.17763

The only relevant part is probably dark mode detection (Windows build number checks might be off), 17763 seems to be outdated Windows 10 version from 2018 (current supported versions are 19044/19045), so no idea how to test it.

If you are really using this version of Windows, try commenting function calls here one-by-one, to narrow it down.

godot/platform/windows/display_server_windows.cpp

Lines 5512 to 5523 in fe01776

	bool dark_mode = ShouldAppsUseDarkMode();
	if (SetPreferredAppMode) {
	SetPreferredAppMode(dark_mode ? APPMODE_ALLOWDARK : APPMODE_DEFAULT);
	} else if (AllowDarkModeForApp) {
	AllowDarkModeForApp(dark_mode);
	}
	if (RefreshImmersiveColorPolicyState) {
	RefreshImmersiveColorPolicyState();
	}
	if (FlushMenuThemes) {
	FlushMenuThemes();
	}

But I'm not sure how it's related to Mono.

I'm using Windows 10 1809, but I aggreed it may not be relevant.

[viksl]

Just to be clear, I have the same issues and I'm on windows 11.

[Delsin-Yu]

Now I'm extra confused since my builds don't seem consistent.

These are what I done for each version:

• I moved every built file to a sub folder (as shown down below) before starting a new build.
• I didn't delete anything inside modules/mono before performing a build.
• I did build with module_mono_enabled=yes argument.
• I did use the built binaries to generate mono glues at the correct location.
• I did ran build_assemblies.py and ensure the results are copied to the dest directory.

These are the builds I made:

[OK] Dev5 [89f70e9]
[OK] Dev5 Mono [89f70e9]

[OK] Main-3 [691bd17]
[Crash!] Main-3 [691bd17]

[OK] Main-2 [84bdc8d]
[Crash!] Main-2 [84bdc8d]

[OK] Main-1 [68ad520]
[Crash!] Main-1 [68ad520]

[OK] Main [fe01776]
[Crash!] Main Mono [fe01776]

This made me rebuild the dev5 afterward：

[OK] Dev5 [89f70e9]
[Sometimes Crash] Dev5 Mono [89f70e9]

And this is the order I followed when building these versions.

[Armynator]

Assuming it's the same problem, for me this is happening since way over a week already. Sometimes it works, but usually it doesn't. I'm not sure when exactly this was introduced, as I'm only rebuilding every 5-10 days. The version I'm currently using is from end of February, which I stayed on because this problem appeared afterwards. Same problem on 2 different machines, Windows 10 and Windows 11. I'm only using Mono builds.

[Armynator]

Just went back and tested through all commits. It started happening with eccdf1a.

3cac010 is still working fine for me.

[Delsin-Yu]

@AThousandShips request: regression, topic:dotnet

[viksl]

If nothing else the PR linked does seem to resolve the issue I was having with the crashes.
Have you tried it if there're some lingering issues on your end?

[Delsin-Yu]

If nothing else the PR linked does seem to resolve the issue I was having with the crashes. Have you tried it if there're some lingering issues on your end?

Will check soon

[Armynator]

#89861 fixed it for me, yay

[Delsin-Yu]

If nothing else the PR linked does seem to resolve the issue I was having with the crashes. Have you tried it if there're some lingering issues on your end?

Can confirm that #89861 has fixed the issue on my end as well.