The exception is thrown and the process doesn't exit on window close

[ynborokh]

Describe the bug

If we have Image and WebView2 control with Visibility=Collapsed at the same window, then, if we close the window, the window disappears, but the process doesn't exit. If the debugger is attached, then the exception is observed.

Steps to reproduce the bug

0. Here is the Visual Studio solution:
   App1.zip

1. Create simple WinUI 3 project:

<!--  App.xaml  -->
<Application
    x:Class="App.App"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" />

// App.xaml.cs
using Microsoft.UI.Xaml;

namespace App;

public partial class App : Application
{
    public App()
    {
        InitializeComponent();
    }

    protected override void OnLaunched(LaunchActivatedEventArgs args)
    {
        m_window = new MainWindow();
        m_window.Activate();
    }

    private Window m_window;
}

<!--  MainWindow.xaml  -->
<Window
    x:Class="App.MainWindow"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Grid>
        <Grid.RowDefinitions>
            <RowDefinition Height="*" />
            <RowDefinition Height="Auto" />
        </Grid.RowDefinitions>
        <WebView2
            Grid.Row="0"
            Source="https://www.google.com"
            Visibility="Collapsed" />
        <Image
            Grid.Row="1"
            Height="30"
            Source="https://www.google.com/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png" />
    </Grid>
</Window>

// MainWindow.xaml.cs
using Microsoft.UI.Xaml;

namespace App;

public partial class MainWindow : Window
{
    public MainWindow()
    {
        InitializeComponent();
    }
}

2. Launch the project and close the window.
3. You'll see in Task Manager that process still remains alive and doesn't exit. If you have a debugger attached, you'll see the following exception message:

Exception thrown at 0x00007FFD0FEA47F8 (threadpoolwinrt.dll) in App1.exe: 0xC0000005: Access violation reading location 0x0000000000000000.

4. If you remove the Image from MainWindow.xaml, then process exits and no exception is thrown.
5. If you have WebView2.Visibility=Visible, then process exits and no exception is thrown.

Expected behavior

Process must exit. No exceptions should be thrown.

Screenshots

No response

NuGet package version

WinUI 3 - Windows App SDK 1.1.3

Windows app type

• UWP
• Win32

Device form factor

Desktop

Windows version

Windows 10 (21H2): Build 19044

Additional context

I observe this problem for both x86 and x64 platforms and for both Debug and Release configurations.
10.0.22621.1 Microsoft.Windows.SDK.BuildTools are used.

[IvanKarpan]

Experiencing the same exact issue, didn't realize it was a conflict between Image and WebView2... Thank you for figuring this out, hope this gets fixed ASAP because we cannot possibly just drop all images from our project...

[ynborokh]

@gabbybilka @ranjeshj are there any updates on this issue?

[MartinRothschink]

I'm facing the same issue. Please investigate and fix. This is a showstopper for my projects.

[MartinRothschink]

This workaround helped: dotnet/maui#7317 (comment)

[ynborokh]

@MartinRothschink Thanks for the link. I've found another workaround: implementing own Main method and calling Environment.Exit manually after app finished working:

[STAThread]
static void Main(string[] _)
{
    WinRT.ComWrappersSupport.InitializeComWrappers();
    Application.Start(AppInitCallback);
    Environment.Exit(0);
}

private static void AppInitCallback(ApplicationInitializationCallbackParams _)
{
    SynchronizationContext.SetSynchronizationContext(
        new DispatcherQueueSynchronizationContext(DispatcherQueue.GetForCurrentThread()));

    new MainWindow().Activate();
}

It helps, because the exception/hang I'm experiencing happens after the return from Main (call stack below). So, by calling Exit I skip the post-Main phase.

threadpoolwinrt.dll!Microsoft::WRL::ActivationFactory<struct Windows::System::Threading::IThreadPoolStatics,class Microsoft::WRL::FtmBase,class Microsoft::WRL::Details::Nil,0>::Release(void)	Unknown
Microsoft.ui.xaml.dll!ThreadPoolService::ReleaseFactories(void)	Unknown
Microsoft.ui.xaml.dll!DeinitializeDll(void)	Unknown
Microsoft.ui.xaml.dll!DllMain�()	Unknown
Microsoft.ui.xaml.dll!dllmain_dispatch()	Unknown
ntdll.dll!LdrpCallInitRoutine()	Unknown
ntdll.dll!LdrShutdownProcess�()	Unknown
ntdll.dll!RtlExitUserProcess()	Unknown
kernel32.dll!ExitProcessImplementation�()	Unknown
ucrtbase.dll!exit_or_terminate_process()	Unknown
ucrtbase.dll!common_exit()	Unknown
App1.exe!__scrt_common_main_seh() Line 295	C++
kernel32.dll!BaseThreadInitThunk�()	Unknown
ntdll.dll!RtlUserThreadStart�()	Unknown

But I believe my approach has its drawbacks, since after Environment.Exit(0) is called, the process immediately exists and so the normal runtime workflow (proper releasing of the runtime resources etc) doesn't happen.

[ynborokh]

This fix seems to fix this issue, so we can close it.