Add defensive error handling for Settings navigation and search

[tburns10]

Summary

Addresses the root cause chain behind the NullReferenceException crash in Settings navigation. Crash dump analysis with WinDbg revealed that Frame.Navigate() can throw native WinUI ABI exceptions that propagate unhandled through multiple code paths.

Changes (3 files)

NavigationService.cs — Defensive try-catch for all Frame.Navigate() call sites:

• Navigate(): Wrap in try-catch, log via Logger.LogError(), return false on failure
• EnsurePageIsSelected(): Add matching try-catch for consistency (also calls Frame.Navigate() unprotected)
• Protects all navigation in the Settings app

ShellViewModel.cs — Fix the crash-causing Frame_NavigationFailed handler:

• Replace throw e.Exception with e.Handled = true + Logger.LogError()
• The original code threw NullReferenceException when e.Exception was null (native WinUI errors don't always marshal to managed Exception objects)
• Mark the event as handled to prevent framework error propagation

ShellPage.xaml.cs — Protect async void SearchBox_QuerySubmitted:

• Wrap entire method body in try-catch
• async void methods that throw after await produce unhandled exceptions that crash the process
• Covers both search indexing (Task.Run) and navigation failures

Crash Dump Evidence

Analysis of PowerToys.Settings_2025_03_26_48636.dmp with WinDbg:

• 4 stowed exception records found at 0x000001c60d3b9100
• Exception chain: SearchBox_QuerySubmitted → Frame.Navigate() fails at native ABI → NavigationFailed fires with null Exception → throw null → NullReferenceException → FailFastWithStowedExceptions
• Root failure in Microsoft.UI.Xaml.dll!DirectUI::Frame::Navigate

Review Notes

• catch (Exception) pattern matches 92.5% of Settings.UI codebase convention
• Logger.LogError() with using ManagedCommon matches standard import pattern
• No security concerns: logged page type names are not sensitive data
• Build verified locally (38/38 applicable tests pass; 111 COM-dependent tests fail identically on main)

[crutkas]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[tburns10]

@crutkas anything I need to do here?

[Copilot]

Pull request overview

This PR hardens the Settings UI navigation and search flows against WinUI navigation failures that can surface as native/ABI exceptions (or as NavigationFailed with a null Exception), preventing process-terminating unhandled exceptions.

Changes:

• Wrap Frame.Navigate() call sites in NavigationService with try/catch, log failures, and return false when navigation cannot be performed.
• Update ShellViewModel’s navigation failure handler to mark failures as handled and log instead of rethrowing e.Exception.
• Add a top-level try/catch to ShellPage’s async void search submission handler to prevent unhandled exceptions after await.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/settings-ui/Settings.UI/Services/NavigationService.cs	Adds defensive exception handling around navigation calls and logs failures instead of letting exceptions propagate.
src/settings-ui/Settings.UI/ViewModels/ShellViewModel.cs	Prevents crashes on NavigationFailed by handling/logging rather than throwing (including null-safe logging).
src/settings-ui/Settings.UI/SettingsXAML/Views/ShellPage.xaml.cs	Prevents async void search submission exceptions from crashing the app by catching/logging the full handler body.