Crash on shutdown (0xC0000005) tearing down a focused TextBox: GetElementIslandInputSite dereferences null input services

[TheBlueSky]

Describe the bug

Closing a WinUI 3 window while a TextBox still has focus crashes the process with an access violation (0xC0000005) inside Microsoft.UI.Xaml.dll during framework shutdown.

CDependencyObject::GetElementIslandInputSite() ends with:

// dxaml/xcp/core/core/elements/depends.cpp:332
return coreServices->GetInputServices()->GetPrimaryRegisteredIslandInputSite();

GetInputServices() returns nullptr once input services have been torn down, so GetPrimaryRegisteredIslandInputSite() runs on a null this and faults reading m_islandInputSiteRegistrations. The text box teardown path reaches it through the RichEdit gripper code:

Microsoft_UI_Xaml!CInputServices::GetPrimaryRegisteredIslandInputSite
Microsoft_UI_Xaml!CDependencyObject::GetElementIslandInputSite
Microsoft_UI_Xaml!TextServicesHost::TxGetWindow
WinUIEdit!CTxtEdit::TxGetWindow
WinUIEdit!CTouchHandlerImpl::ShowGrippersHelper
WinUIEdit!CTouchHandlerImpl::ShowGrippers
WinUIEdit!CTouchHandlerImpl::HideGrippersWithTlsSafety
WinUIEdit!CTxtEdit::OnTxInPlaceDeactivate
Microsoft_UI_Xaml!CTextBoxBase::Destroy
Microsoft_UI_Xaml!CTextBox::~CTextBox
Microsoft_UI_Xaml!CTextCore::~CTextCore
Microsoft_UI_Xaml!CCoreServices::~CCoreServices
Microsoft_UI_Xaml!CommonBrowserHost::DetachCore
Microsoft_UI_Xaml!CXcpBrowserHost::Deinit
Microsoft_UI_Xaml!CJupiterControl::Deinitialize
Microsoft_UI_Xaml!DirectUI::DXamlCore::Deinitialize
Microsoft_UI_Xaml!DirectUI::WindowsXamlManager::XamlCore::Close
Microsoft_UI_Xaml!DirectUI::XamlCoreNewShutdown::OnFrameworkShutdownStarting

FAILURE_BUCKET_ID: INVALID_POINTER_READ_c0000005_Microsoft.UI.Xaml.dll!CInputServices::GetPrimaryRegisteredIslandInputSite
Microsoft_UI_Xaml!CInputServices::GetPrimaryRegisteredIslandInputSite+9
[InputServices.cpp @ 194]

This is the same crash Jon Wiswall (@jonwis) reported in #11063. That PR proposes the fix but has been open and unrebased since April, so I am filing this issue to track it (per his suggestion) with a fresh PR to follow.

Why is this important?

Any app that leaves a text input focused when the user closes the window dies with an access violation instead of exiting cleanly. It is silent to the user but shows up as an Application Error / WER crash for every session, which pollutes crash telemetry and makes real crashes hard to spot. It also blocks anything that runs on clean shutdown — flushing settings, saving session state, or an exit code that CI can trust.

Focus sitting on a text box at close time is the normal case for form-style and search-style apps, so this is easy to hit without doing anything unusual.

Steps to reproduce the bug

Minimal repro: an unpackaged WinUI 3 app that focuses a TextBox on load and does nothing else.

ReproPage.xaml

<Page
    x:Class="TextInputCloseCrashRepro.App.ReproPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Grid Padding="32">
        <TextBox x:Name="FocusedTextBox"
                 Header="Focused TextBox"
                 Text="Focus stays here until the window closes."
                 VerticalAlignment="Center" />
    </Grid>
</Page>

ReproPage.xaml.cs

public sealed partial class ReproPage : Page
{
    public ReproPage()
    {
        InitializeComponent();
        Loaded += OnLoaded;
    }

    private void OnLoaded(object sender, RoutedEventArgs e)
    {
        _ = FocusedTextBox.Focus(FocusState.Programmatic);
        FocusedTextBox.SelectAll();
    }
}

App.xaml.cs

public partial class App : Application
{
    private Window _window;

    public App() => InitializeComponent();

    protected override void OnLaunched(LaunchActivatedEventArgs args)
    {
        _window = new Window
        {
            Title = "TextInputCloseCrashRepro",
            Content = new ReproPage(),
        };

        _window.Activate();
    }
}

The project is net8.0-windows10.0.19041.0, WindowsPackageType=None, UseWinUI=true.

1. Publish it unpackaged and self-contained:

   dotnet publish .\TextInputCloseCrashRepro.App.csproj `
     --configuration Release --runtime win-x64 `
     -p:SelfContained=true -p:WindowsAppSDKSelfContained=true `
     -p:PublishSingleFile=true -p:IncludeNativeLibrariesForSelfExtract=true

2. Run the published EXE.

3. Leave the TextBox focused (it is focused on load).

4. Close the window.

Actual behavior

The process terminates with 0xC0000005. Exit code is -1073741819 and an Application Error (Event ID 1000) is logged against Microsoft.UI.Xaml.dll.

Reproduced 3/3 on every affected version tested:

Windows App SDK	Microsoft.UI.Xaml.dll	Result
1.7.260224002 (latest 1.7)	3.1.7.0	3/3 crash
1.8.260317003	3.1.8.0	3/3 crash
1.8.260804001 (latest 1.8)	3.1.8.0	3/3 crash
2.4.0 (latest stable)	3.2.3.0	3/3 crash

Two control runs on 2.4.0 isolate the trigger:

Variation	Result
Same app, TextBox never programmatically focused	3/3 clean exit (0)
Same app, focus moved off the TextBox in AppWindow.Closing	3/3 clean exit (0)

So it needs a focused text input at teardown, and moving focus away before shutdown starts is a viable app-side workaround.

Expected behavior

The app exits cleanly with exit code 0, the same as it does when no text input is focused.

NuGet package version

2.4.0 (also 1.8.260804001, 1.8.260317003, 1.7.260224002)

Windows version

Windows 11 (25H2): Build 26200

Also reported on Build 26100, so it does not look OS-build specific.

Additional context

GetPrimaryRegisteredIslandInputSite() already handles the empty case correctly and returns nullptr, so the bug is not in that function — the null pointer is the CInputServices instance itself.

All callers of GetElementIslandInputSite() pass the result straight to CInputServices::GetUnderlyingInputHwndFromIslandInputSite(), which is declared _In_opt_ and null-checks its argument. A null return is therefore already an expected and handled result, which makes the null guard in #11063 a safe fix.

Possibly related, but distinct and already fixed: #9070.