Debug build crashing with 0xc0000374 (STATUS_HEAP_CORRUPTION) since update to WinAppSdk 1.5.X

[AMArostegui]

Describe the bug

Since updating to WinAppSdk 1.5.X our application crashes with the above exception. As soon as I revert back to WinAppSdk 1.4.X or lower, it stops happening. We're on .NET 6 if that's important.

I've never seen it crashing on a release build so our customers won't be impacted, but it's a time sink since it happens very often for the developers. Out of 3 developers, one is not experiencing the problem.

Visual Studio won't trap the exception and the process suddenly stops, but I get a Windows event viewer entry and the excepction is logged in the output window. The debug build crashes no matter if Visual Studio is attached, or I run the executable on its own.

I've run the program with WinDbg and I'm sharing the callstack below. I've edited four frames for privacy reasons, the line that triggers the problem seems to be:

public const string ColorsDictionaryPath = "ms-resource:///Files/Styles/Colors.xaml";
(...)
ColorsDictionary = new ResourceDictionary { Source = new Uri(ColorsDictionaryPath, UriKind.RelativeOrAbsolute) };

If I click 'continue' WinDbg is able to swallow the exception and keep running, but it seems I cannot catch such exception in VS, it doesn't show in the exception list.

Steps to reproduce the bug

Not applicable

Expected behavior

Debug build should not crash

Screenshots

No response

NuGet package version

Windows App SDK 1.5.5: 1.5.240627000

Packaging type

Unpackaged

Windows version

Windows 11 version 22H2 (22621, 2022 Update), Windows 10 version 22H2 (19045, 2022 Update)

IDE

Visual Studio 2022

Additional context

WinDbg Callstack edited.txt

[AMArostegui]

Another example of a different situation when the program is crashing:

WinDbg Callstack edited 2.txt

I think localization might have something to do, since the developer who isn't getting the crashes is not using a translated operating system.

[AMArostegui]

Turns out, the repository name I'm using is quite long.

If I rename the repository folder to a shorter name, the problem suddenly disappears

[lhak]

I actually observed the same issue (but in a different configuration) and moving the output folder also helps in my case. Still, the path is far shorter than MAX_PATH (not even talking about long path support), so I guess there is a bug somewhere in the winui code.

[lhak]

I do not think that this should be closed as it still reproduces with path lengths smaller than MAX_PATH even with the latest appsdk release.