Native crash (0xc0000005) in Microsoft.UI.Xaml.dll when UIA clients enumerate NavigationView with programmatic items

[hoopsomuah]

Describe the bug

WinUI 3 crashes with an access violation (0xc0000005) in Microsoft.UI.Xaml.dll when external UIA (UI Automation) clients deeply enumerate the accessibility tree of a NavigationView containing programmatically-added NavigationViewItem elements. The crash is in native XAML code — no managed frames on the crashing thread.

Steps to reproduce

1. Create a WinUI 3 app with a NavigationView
2. Programmatically add 20+ NavigationViewItem elements in code-behind, some with nested children (hierarchical items)
3. Run the app (unpackaged, WindowsPackageType=None)
4. Use any UIA client to deeply walk the accessibility tree:
   • FlaUInspect (hover over the NavigationView area)
   • FlaUI FindAllChildren() recursive walk
   • Accessibility Insights tree view
5. App crashes within seconds of the UIA enumeration

Crash details

Two crash sites observed:

Exception	Offset	Description
0xc0000005 (Access Violation)	Microsoft.UI.Xaml.dll+0x35f9d	Null pointer dereference during automation peer measure/arrange
0xc000027b (Stowed Exception)	Microsoft.UI.Xaml.dll+0x39dec5	WinRT stowed exception during UIA tree walk

From Windows Event Log:

Faulting module: Microsoft.UI.Xaml.dll, version 3.1.8.0
Exception code: 0xc0000005
Fault offset: 0x0000000000035f9d

From dotnet-dump:

OS Thread Id: 0x2bd9c (0)
  Child SP               IP Call Site
  000000EC4F77E200 00007FFA6F948A15 ABI.Microsoft.UI.Xaml.IApplicationStaticsMethods.Start(...)
  000000EC4F77E330 00007FFA6F94762C Microsoft.UI.Xaml.Application.Start(...)
  000000EC4F77E370 00007FFA6F94714B WinUiSample.Program.Main(System.String[])

No managed exception — crash is entirely in native code.

Key observations

• App is stable indefinitely when no UIA client is interacting (tested 60s+)
• Crash is 100% reproducible when UIA deeply enumerates the NavigationView subtree
• Shallow UIA queries (depth 1-2) generally survive; deep walks (depth 5+) always crash
• Adding InfoBadge to NavigationViewItem makes the crash more frequent (different automation peers in the tree)
• Crash does not occur with XAML-declared NavigationViewItem elements (only programmatic)

Workarounds

1. Limit UIA tree enumeration depth to 3 levels
2. Wrap per-node enumeration in try/catch for COMException and SEHException
3. When encountering a NavigationView in the UIA tree, enumerate only direct children and stop recursion

Environment

• WinUI 3 / WinAppSDK: Microsoft.UI.Xaml.dll 3.1.8.0
• Target: net10.0-windows10.0.26100.0
• .NET SDK: 10.0.201
• OS: Windows 11
• Packaging: Unpackaged (WindowsPackageType=None)
• DPI: PerMonitorV2 via app.manifest

[hoopsomuah]

Update: Crash is NOT specific to NavigationView

After further investigation, the crash at Microsoft.UI.Xaml.dll+0x35f9d is not specific to NavigationView. We reproduced the identical crash after completely replacing all NavigationView and InfoBadge controls with SplitView + ListView:

What we tried (all still crash at the same offset)

Approach	Result
Remove nested NavigationViewItem children (flat hierarchy)	Still crashes
AccessibilityView="Raw" on NavigationView	Still crashes
Subclass NavigationView with custom OnCreateAutomationPeer returning empty children	WinUI 3 XAML parser silently fails to instantiate the subclass (no template resolution)
Replace NavigationView with SplitView + ListView	Still crashes at same offset
Remove all InfoBadge controls	Still crashes at same offset
Remove ALL NavigationView and InfoBadge from the entire app	Still crashes at same offset

Conclusion

The crash at 0x35f9d in Microsoft.UI.Xaml.dll version 3.1.8.0 is triggered by any deep UIA tree enumeration of a WinUI 3 app with a moderately complex visual tree. It is a general defect in the automation peer infrastructure, not isolated to NavigationView or InfoBadge.

Updated repro

1. Create any WinUI 3 desktop app with a reasonably complex XAML tree (SplitView, ListView, Frame, TextBox, etc.)
2. Run the app (unpackaged, WindowsPackageType=None)
3. Open FlaUInspect (UIA3 mode) and inspect the app's window
4. App crashes with 0xc0000005 at Microsoft.UI.Xaml.dll+0x35f9d

Viable workaround

The only effective workaround is on the UIA client side: cap tree enumeration depth (we use depth 3) and wrap per-node enumeration in try/catch for COMException/SEHException. This is what we've implemented in our FlaUI-MCP tooling.

App-side mitigations (control replacement, AccessibilityView, custom peers) do not prevent the crash because the bug is in the native automation peer infrastructure, not in any specific control's peer implementation.