Build process of WinUI3 project causes bluescreen error

[Ajith-GS]

Describe the bug

When building a WinUI 3 project, the system sometimes crashes and displays a blue screen error . The system goes to a blue screen as soon as the build process starts.

The dump file of Memory details is given below:

Steps to reproduce the bug

1. Create a WinUI 3 project in VS 2022.
2. Build the project.
   The issue is not reproducible every time, but it is not rare.

Expected behavior

No response

Screenshots

No response

NuGet package version

Windows App SDK 1.6.3: 1.6.241114003

Packaging type

Packaged (MSIX), Unpackaged

Windows version

Windows 10 version 22H2 (19045, 2022 Update)

IDE

Visual Studio 2022

Additional context

OS Version: 22H2 (OS Build 19045.5131)
Visual Studio Version: 17.12.3

[DarranRowe]

How is the general health of the build system?

There are two major types of issues that can cause unexpected bug checks, regularly too. The first is if the Windows install is subtly broken and the second is hardware problems.

Commands like

dism /online /cleanup-image /scanhealth

sfc /scannow

can allow you to check if there is anything majorly problematic. The dism command checks the winsxs directory, where sfc checks the rest.

Hardware is also not an all or nothing situation. Hardware can be working well enough that it will keep working seemingly correctly for ages, but then suddenly just fail. In fact, with the MEMORY_MANAGEMENT bug check code, I would immediately be checking the system RAM for errors. But remember that storage errors, due to the page file, and power errors can also cause this type of bug check.

RAM errors are pretty interesting in this situation. It is easy to believe that the firmware and Windows will know if RAM is bad, but it is very possible for circumstances to result in some RAM issues not being detected. While I admit this will be anecdotal, but one system of mine ended up with one module from the second set of RAM on a channel failing while in the system. The firmware had no issues at all, and Windows kept working. The only sign I had of something not being quite right was when was under pressure in RAM. As soon as Windows went past 32GiB (the system had 64GiB total) allocated, anything allocated would only ever read 0s. It became obvious very quickly that RAM was the problem. Interestingly, at this point I removed second set of RAM, booted the system into the firmware, shut the system down and put the RAM back in and all of the sudden the firmware was indicating that there was a RAM error. It is very possible for RAM to fail while in use and the system just doesn't notice it.

Because of how C++ works, and especially C++/WinRT, the precompiled headers and template expansion can take up a huge amount of address space, which can correspond to a huge amount of RAM if your build system has enough so that it doesn't have to page. What's more, Visual Studio has parallel build set by default. To use my system as an example, it is possible for Visual Studio to run 48 instances of cl.exe which each can take 4GiB+ of address space each. So depending on the project type, amount of physical RAM and the fact that Windows seems to prefer allocating RAM linealry, then it is very possible that this issue is only happening in Visual Studio and only with a WinUI 3 build due to how much memory it can eat up.

If you really believe that this isn't a hardware issue, then I suggest you report this through the feedback hub and be sure to provide the minidumps that you have captured. This could be a Windows issue and that is the best place to report it. If you don't want to try your luck with the feedback hub, then a paid incident for Windows Professional Support or Windows Developer Support would be a better course of action. This will allow a Windows engineer to look at the issue in a relatively short period of time and help you through the problem.