Breakpoint experience unhelpful in WinUI Apps

[dotMorten]

Describe the bug

When you write code that causes an exception to occur, very often the exception will be shown in App.xaml's UnhandledException handler, instead of where the exception occurred. This significantly slows down the inner developer loop, because extra time is spent trying to figure out where the exception occurred. It can also easily be (mis)interpreted as a bug with the Windows App SDK and not user code, giving a worse impression of the SDK overall.

This is part of these death-by-1000-razor cut issues that makes the developer experience really poor.

Steps to reproduce the bug

1. Create a new WinUI project.
2. in MainWindow.xaml.cs add the following code:

        public MainWindow()
        {
            InitializeComponent();
            this.Activated += MainWindow_Activated;    
        }

        private void MainWindow_Activated(object sender, WindowActivatedEventArgs args)
        {
            throw new ArgumentException(); // Imagine you do something here that occasionally causes an exception
        }

3. Run the application and observe the exception experience:
   

Expected behavior

This is the experience I would have preferred, which helps me faster realize the issue and allow me to move on:

That will also give me access to the state in the thread right here and inspect what went wrong.

As a workaround this can be achieved by realizing this is an ArgumentException and turning on first-chance exceptions, but it requires being able to reproduce the issue right then and there with that first-chance break set on, but from the developer's point of view this isn't a first chance, since there is no try-catch.

Also if you repeat this example in WPF, you'll get the correct breakpoint, .

Screenshots

No response

NuGet package version

Windows App SDK 1.8 Experimental 2: 1.8.250515001-experimental2

Packaging type

Packaged (MSIX)

Windows version

Windows 11 version 24H2 (22621, October 2024 Update)

IDE

Visual Studio 2022

Additional context

No response

[RDMacLachlan]

Thank you @dotMorten

[lhak]

I actually see the expected behavior if "enable just my code" is enabled in the debug settings. I had for some reason turned off that setting in the past and in this case I also observe that it goes directly to the unhandled exception handler.