Unable to close WinUI apps normally in debug mode

Question

Unable to close WinUI apps normally in debug mode

Hong 1,666

If I run any of my WinUI apps in the debug mode (F5) and try to close the app by clicking the "x" button in the top right corner, the app keeps throwing the following exception indefinitely. I have to use VS to force the app to stop or use Task Manager to stop it.

 Exception thrown at 0x00007FFA2E8BC474 (Microsoft.ui.xaml.dll) in MyApp.exe: 0xC0000005: Access violation reading location 0x00000001C000004D.

Stack trace:

[Exception thrown at 0x00007FFA2E8BC474 (Microsoft.ui.xaml.dll) in MyApp.exe: 0xC0000005: Access violation reading location 0x00000001C000004D.]	
>	Microsoft.ui.xaml.dll!00007ffa2e8bc474()	Unknown
 	Microsoft.ui.xaml.dll!00007ffa2e8bc87c()	Unknown
 	Microsoft.ui.xaml.dll!00007ffa2e6e5992()	Unknown
 	Microsoft.ui.xaml.dll!00007ffa2e610d0a()	Unknown
 	Microsoft.ui.xaml.dll!00007ffa2e60e36d()	Unknown
 	Microsoft.ui.xaml.dll!00007ffa2e7a8b98()	Unknown
 	Microsoft.ui.xaml.dll!00007ffa2e7a633e()	Unknown
 	Microsoft.ui.xaml.dll!00007ffa2e7a7913()	Unknown
 	Microsoft.ui.xaml.dll!00007ffa2e7a8d35()	Unknown
 	user32.dll!00007ffaab5d52c6()	Unknown
 	user32.dll!00007ffaab5d4d8c()	Unknown
 	Microsoft.VisualStudio.Debugger.Runtime.Impl.dll!00007ff9b00e1bf0()	Unknown
 	Microsoft.UI.Windowing.Core.dll!00007ffa2df4e123()	Unknown
 	Microsoft.UI.Windowing.Core.dll!00007ffa2df4c144()	Unknown
 	Microsoft.UI.Windowing.Core.dll!00007ffa2df3698d()	Unknown
 	Microsoft.UI.Windowing.Core.dll!00007ffa2df384bf()	Unknown
 	Microsoft.UI.Windowing.Core.dll!00007ffa2df4cfa4()	Unknown
 	Microsoft.UI.Windowing.Core.dll!00007ffa2df4d477()	Unknown
 	user32.dll!00007ffaab5d52c6()	Unknown
 	user32.dll!00007ffaab5d4b4c()	Unknown
 	user32.dll!00007ffaab5ff673()	Unknown
 	ntdll.dll!00007ffaab944de4()	Unknown
 	win32u.dll!00007ffaa92b1364()	Unknown
 	user32.dll!00007ffaab5d7e6b()	Unknown
 	user32.dll!00007ffaab5d7d04()	Unknown
 	uxtheme.dll!00007ffaa5a967bd()	Unknown
 	uxtheme.dll!00007ffaa5ae8956()	Unknown
 	uxtheme.dll!00007ffaa5a988d6()	Unknown
 	uxtheme.dll!00007ffaa5a98091()	Unknown
 	user32.dll!00007ffaab5d79ba()	Unknown
 	Microsoft.ui.xaml.dll!00007ffa2e7a7736()	Unknown
 	Microsoft.ui.xaml.dll!00007ffa2e7a8d35()	Unknown
 	user32.dll!00007ffaab5d52c6()	Unknown
 	user32.dll!00007ffaab5d4d8c()	Unknown
 	Microsoft.VisualStudio.Debugger.Runtime.Impl.dll!00007ff9b00e1bf0()	Unknown
 	Microsoft.UI.Windowing.Core.dll!00007ffa2df4e123()	Unknown
 	Microsoft.UI.Windowing.Core.dll!00007ffa2df4c144()	Unknown
 	Microsoft.UI.Windowing.Core.dll!00007ffa2df3698d()	Unknown
 	Microsoft.UI.Windowing.Core.dll!00007ffa2df384bf()	Unknown
 	Microsoft.UI.Windowing.Core.dll!00007ffa2df4cfa4()	Unknown
 	Microsoft.UI.Windowing.Core.dll!00007ffa2df4d477()	Unknown
 	user32.dll!00007ffaab5d52c6()	Unknown
 	user32.dll!00007ffaab5d5d9d()	Unknown
 	Microsoft.ui.xaml.dll!00007ffa2e74b6d6()	Unknown
 	Microsoft.ui.xaml.dll!00007ffa2e74bc36()	Unknown
 	Microsoft.ui.xaml.dll!00007ffa2e55409b()	Unknown
 	[External Code]	
 	hostpolicy.dll!00007ffa1c1add0a()	Unknown
 	hostpolicy.dll!00007ffa1c1adfac()	Unknown
 	hostpolicy.dll!00007ffa1c1aef21()	Unknown
 	hostfxr.dll!00007ffa1c60d56b()	Unknown
 	hostfxr.dll!00007ffa1c61029c()	Unknown
 	hostfxr.dll!00007ffa1c612676()	Unknown
 	hostfxr.dll!00007ffa1c61079d()	Unknown
 	hostfxr.dll!00007ffa1c608998()	Unknown
 	MyApp.exe!00007ff6cfe62f48()	Unknown
 	MyApp.exe!00007ff6cfe633c6()	Unknown
 	MyApp.exe!00007ff6cfe73b28()	Unknown
 	kernel32.dll!00007ffaaa58cd87()	Unknown
 	ntdll.dll!00007ffaab88caec()	Unknown

If I start the app without debugging, the app can be closed normally.

Could anyone shed some light on this?

0 comments

1 answer

Your answer

Answer 1

Hi @Hong ,

Having to force-stop the app instead of closing it normally interrupts your debugging workflow. The fact that the apps close normally without debugging narrows the investigation to shutdown with the debugger attached. The 0xC0000005 error is a native access violation, but the fault appearing in Microsoft.ui.xaml.dll does not by itself identify the component responsible.

I would first isolate Visual Studio's XAML debugging features. XAML Hot Reload supports WinUI 3 and can attach XAML tooling during F5 debugging, making it a useful comparison for the behavior you described. This does not yet establish that Hot Reload is causing the exception.

Use the same affected app, keeping its code, SDK version, and other debugger settings unchanged:

Stop debugging, open Tools > Options, and search for XAML. On the XAML Hot Reload or XAML Diagnostics page, temporarily clear Enable in-app toolbar. Start a new F5 session and close the window with X.
If the exception remains, stop debugging and temporarily clear Enable XAML Hot Reload. If your Visual Studio uses the newer XAML Diagnostics page, clear Enable for WinUI (including .NET MAUI) instead. Start another F5 session and repeat the close test.
If neither change helps, restore the original settings and try a fresh WinUI Blank App with the same Windows App SDK version, architecture, packaging type, and debugger settings.

If either of the first two tests allows normal shutdown, leaving the relevant feature disabled can provide a temporary workaround, with that XAML debugging functionality unavailable. If the Blank App also fails, the shared environment needs further investigation. If it closes normally, the next focus is the affected app's controls and shutdown code.

If an affected app still fails and uses WebView2, try a separate cleanup comparison with the original XAML debugging settings restored. Microsoft's WinUI 3 WebView2 sample calls WebView2.Close() in the window's Closed handler. Its comment describes a debug-time shutdown issue involving an expected winrt::hresult_error; it does not establish the cause of your access violation.

For a control named MyWebView, register this after InitializeComponent() in its owning window's constructor:

Closed += (_, _) =>
{
    MyWebView?.Close();
};

Apply the cleanup to each WebView2 owned by the window. Skip this comparison if the app does not use WebView2.

Please share which test changes the behavior, your Visual Studio and Windows App SDK versions, whether the app is packaged or unpackaged, and whether it uses WebView2. If the Blank App also fails, please include your Windows build. A full debug log is not needed at this stage. If any of the options or steps are unclear, please let me know.