WinUI application closed by 'X' but remains as dormant proc

[sigmarsson]

Describe the bug

I close the WinUI application by pressing 'X' on the window but remains dormant and must kill it in the Task Manager.

Steps to reproduce the bug

Create new app and derive App : PrismApplication

Expected behavior

No response

Screenshots

No response

NuGet package version

WinUI 3 - Windows App SDK 1.1 Preview 3: 1.1.0-preview3

Windows app type

• [ ] UWP
• [X] Win32

Device form factor

Desktop

Windows version

Windows 10 (21H2): Build 19044

Additional context

Request the information you need and ll provide.

[michael-hawker]

@Sergio0694 this is what you were kind of seeing with ComputeSharp too, eh?

[Sergio0694]

Sounds similar, yes. In my case I could narrow this down to specifically when a swap chain was rendering. If that's not the case, the app closes just fine for me. I've opened an issue tracking that issue here: #7153.

[marb2000]

Can you still repro this in 1.1 Stable?

[sigmarsson]

Yes, still in 1.1 persist. Click on 'X' and the process becomes a backgrdound proc , which I can wintess in Task Manager.

It moves from the "Apps" list to the "Background Processes" list.

[sigmarsson]

@marb2000 feel free to request whatever additional information you may need.

[sigmarsson]

@marb2000 still able to reproduce it in version 1.1.3 Feel free to request any more specific context.

[pratikone]

I am looking at this issue now. Btw, cool shader program. it is fun to investigate 😊

[Sergio0694]

@pratikone That's awesome, and thank you! 😄

Also let me know if you need any help with the repro - that branch I shared is a bit out of date, so you might also want to just checkout to main (which is on WASDK 1.2 latest now) and see if the issue still repros there anyway once removing the workaround in App.xaml.cs to just force terminate the process. I can also help with that if needed 🙂

[pratikone]

@Sergio0694 sure, i will check it out.

[pratikone]

@Sergio0694 i have some lead. I have a workaround (you can also continue the workaround you have).

the bug doesn't appear if your app is self-contained. if you edit csproj of your app and set <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>, this problem goes away. I am trying it on ComputeSharp.SwapChain.WinUI.csproj in your main repo. This is good news. though switching to self contained will increase your package size as everything will be bundled together.

So, the bug only appears if you are using winappsdk as a runtime rather than a self contained binary. This is an interesting lead. Do you have a swap chain winui sample project which doesn't include compute sharp library ? It will simplify debugging for me.

(@bpulliam / @gabbybilka we should add a swapchain sample winui app in winappsdk samples)

[Sergio0694]

That is very interesting, good find! I'm not too concerned about the package size right now since I'm not currently publishing that app in the WinUI 3 version anyway (I'm only publishing the UWP version right now, as it's noticeably faster, consumes less resources, ships as an AOT binary and also has a much smaller package size), but I might as well leave the workaround in there for now to keep things simpler. I hope this discovery will help the investigation though! 😄

"Do you have a swap chain winui sample project which doesn't include compute sharp library?"

Unfortunately I don't, no 🥲 Getting a full swap chain sample running from scratch is a fair amount of work, and I've had no motivation to try to do that without reusing my library, given those samples are all meant to be a showcase of it. It's certainly possibly to do so (and the code in the library can also be used as a reference, in part), it's just not trivial work and it might require some time 😅

[castorix]

"Do you have a swap chain winui sample project which doesn't include compute sharp library?"

BTW, I had posted a sample with the Media Engine : CMediaEngine.cs (in CreateSwapChain function) (I have also done others with Direct2D, that I did not upload yet...)

[sigmarsson]

@pratikone , the property having mentioned not solving me the problem.

[pratikone]

You are right. in successive debugging sessions, the bug reproduced even when the app was self contained. I guess, in earlier times, VS killed the app a few times. Don't know how that happened. Definitely this issue appears whether app is packaged or self contained.

Also thanks @castorix for that media engine link. I tested it out. It doesn't show the bug yet. Do I need to comment out somewhere for it to show the issue ?

[pratikone]

@gegao18 can you take a look at this ? it looks like on using swap chain with D3D , memory is being kept alive which is causing the app to not quite during exit. WinUI correctly goes through all its cleanup rountine but the app continues to run.

easy repro : download https://github.com/Sergio0694/ComputeSharp, run ComputeSharp.SwapChain.WinUI sln.

It has the code to forcibly null ShadeRunner variable as well as a shutdown timer. You can comment those out for the bug to repo. Appears in both runtime as well as self contained configs.

[sigmarsson]

Upon 'X' I witness this :

[sigmarsson]

Upon 'X' I witness this today , does that help ?

[pratikone]

Every piece of debugging information helps. Thanks for doing it. 👍🏾

[sigmarsson]

With 1.4 the application deployed, X but the proc remains dormant.

[JesseCol]

Hi sigmarsson, do you have a minimal repro of this? Sorry if I missed it somewhere in the thread. Thanks!

[michael-hawker]

Hi sigmarsson, do you have a minimal repro of this? Sorry if I missed it somewhere in the thread. Thanks!

@JesseCol the other similar issue mentioned had a repro repo here: https://github.com/microsoft/microsoft-ui-xaml/issues/7153#issue-1250217420

Though there wasn't clarity on if it was the exact same issue, it did get closed as a duplicate of this one.

[JesseCol]

Thanks! I built and debugged this project locally: https://github.com/Sergio0694/SwapChainWinUI3Repro

From what I can tell, the CLR is keeping the process alive because there's a managed thread that's still running -- a thread that ComputeSharp had created.

I fixed the sample by doing this:

1. I added an Unloaded handler for ShaderPanel that calls StopRenderLoop().
2. I upgraded the project to WinAppSDK 1.4 (it was on an older version where the Unloaded events weren't always raised correctly).

The Xaml looks like this:

<winui:AnimatedComputeShaderPanel x:Name="ShaderPanel" Loaded="AnimatedComputeShaderPanel_Loaded" Unloaded="ShaderPanel_Unloaded" />

The C# is like this:

    public void StopRenderLoop()
    {
        ShaderPanel.ShaderRunner = null;
    }

    private void ShaderPanel_Unloaded(object sender, RoutedEventArgs e)
    {
        StopRenderLoop();
    }

As far as I know this is all by design, so I'm closing this one out. Feel free to comment and let me know if I missed something. Thanks!

[Sergio0694]

Hey @JesseCol, thank you for looking into this! My AnimatedComputeShaderPanel already subscribes to Unloaded internally to stop the render thread (here), so I wonder if the issue there wasn't just caused by WinAppSDK using an older version where that event wasn't being raised, and that StopRenderLoop() call was not actually the one fixing the issue.

I tried again in my sample app (should just be able to F5 deploy it if you open the solution in VS 17.8), and I am not entirely sure about what I'm seeing. When I just run the app normally, I get this (which is fine):

Closing the window, the process immediately becomes this:

With just the runtime broker being left there, with 0.1 memory use. It seems to then just remain like that for a bit (say, 1-2 minutes), and then it eventually goes away. Is this the expected behavior? The thing is that I'm not entirely sure how this could be explained by eg. the CLR remaining alive because a thread was still running, because if that was the case, then why would the actual process for the app still go away, and the memory use go down to just 0.1 MB? 🤔

[JesseCol]

Agreed, if the process app process has exited, it doesn't sound like anything due to the CLR (or WinAppSDK / WinUI). I'm sorry, I don't have much experience with RuntimeBrokers, so I don't have a good answer to your question.

[sigmarsson]

I still experience that the process remains dormant upon 'X' and stays as "Background process" in Task manager. Could either procmon or windbg lend a clue and if so, what specific filter shall I apply to narrow this down ? SDK 1.5.1.

[sigmarsson]

ModLoad: 00007ffdf6350000 00007ffdf6378000 C:\WINDOWS\system32\edputil.dll ModLoad: 00007ffe0abe0000 00007ffe0ac1d000 C:\WINDOWS\SYSTEM32\windows.staterepositoryclient.dll ModLoad: 00007ffe09f40000 00007ffe09fa0000 C:\WINDOWS\SYSTEM32\capauthz.dll ModLoad: 00007ffddae70000 00007ffddaea1000 C:\Windows\System32\Windows.Energy.dll ModLoad: 00007ffdee700000 00007ffdee778000 C:\Users\weath\source\repos\Weather.History\Weather.History.Windows\bin\x64\Debug\net8.0-windows10.0.22621.0\AppX\wuceffectsi.dll ModLoad: 00007ffe0c4c0000 00007ffe0c4ea000 C:\WINDOWS\SYSTEM32\Cabinet.dll ModLoad: 000001df9cd60000 000001df9cd6a000 C:\Users\weath\source\repos\Weather.History\Weather.History.Windows\bin\x64\Debug\net8.0-windows10.0.22621.0\AppX\SkiaSharp.HarfBuzz.dll ModLoad: 00007ffe18cd0000 00007ffe18f03000 C:\WINDOWS\system32\dbghelp.dll ModLoad: 00007ffe0c510000 00007ffe0c55b000 C:\Windows\System32\CapabilityAccessManagerClient.dll ModLoad: 00007ffde1970000 00007ffde197c000 C:\Windows\System32\LocationFrameworkPS.dll ModLoad: 00007ffde8400000 00007ffde847e000 C:\WINDOWS\SYSTEM32\PhotoMetadataHandler.dll ModLoad: 00007ffde7a90000 00007ffde7aa5000 C:\Windows\System32\threadpoolwinrt.dll ModLoad: 00007ffe03280000 00007ffe032a8000 C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.3\System.Linq.Queryable.dll ModLoad: 000001df9cf80000 000001df9cfa0000 C:\Users\weath\source\repos\Weather.History\Weather.History.Windows\bin\x64\Debug\net8.0-windows10.0.22621.0\AppX\HarfBuzzSharp.dll ModLoad: 000001df9ce30000 000001df9ce38000 C:\Users\weath\source\repos\Weather.History\Weather.History.Windows\bin\x64\Debug\net8.0-windows10.0.22621.0\AppX\Geolocation.dll (6bd8.6a08): Windows Runtime Originate Error - code 40080201 (first chance) (6bd8.6a08): Windows Runtime Originate Error - code 40080201 (first chance) WebView is unable to complete this operation because it is no longer valid. Controller close API is called. You shouldn't call this API after WebView is closed.(6bd8.6a08): C++ EH exception - code e06d7363 (first chance) (6bd8.6a08): C++ EH exception - code e06d7363 (first chance) Microsoft.Web.WebView2.Core.dll!00007FFCFFB7CDBE: ReturnHr(1) tid(6a08) 8007139F The group or resource is not in the correct state to perform the requested operation. Msg:[winrt::hresult_error: The group or resource is not in the correct state to perform the requested operation.] (6bd8.6a08): C++ EH exception - code e06d7363 (first chance) (6bd8.6a08): Windows Runtime Originate Error - code 40080201 (first chance) (6bd8.6a08): C++ EH exception - code e06d7363 (first chance) (6bd8.6a08): C++ EH exception - code e06d7363 (first chance) Microsoft.Web.WebView2.Core.dll!00007FFCFFB7CC92: ReturnHr(2) tid(6a08) 8007139F The group or resource is not in the correct state to perform the requested operation. Msg:[winrt::hresult_error: The group or resource is not in the correct state to perform the requested operation.] (6bd8.6a08): C++ EH exception - code e06d7363 (first chance) ModLoad: 00007ffde3db0000 00007ffde41f5000 C:\WINDOWS\SYSTEM32\UIAutomationCore.DLL ModLoad: 00007ffe1b4a0000 00007ffe1b543000 C:\WINDOWS\SYSTEM32\sxs.dll mincore\com\oleaut32\dispatch\ups.cpp(2126)\OLEAUT32.dll!00007FFE1C9B470C: (caller: 00007FFE1C9B49FA) ReturnHr(1) tid(6a08) 8002801D Library not registered. Microsoft.ui.xaml.dll!00007FFD2423FFEB: 8001010E - RPC_E_WRONG_THREAD

... as windbg suggests the WebView2 isn't gracefully terminated.

            Window.Closed += (s, e) =>
            {
                var eventAggregator = Container.Resolve<IEventAggregator>();

                eventAggregator.GetEvent<TerminateEvent>().Publish(new object());
            };

_eventAggregator.GetEvent<TerminateEvent>().Subscribe(OnDispose, ThreadOption.UIThread);

        public void Dispose()
        {
            MyWebView.NavigateToString(new Uri("about:blank").ToString());
            MyWebView.Close();
        } 

        private void OnDispose(object x)
        {
            Dispose();
        }

how shall I shutdown it ?

[sigmarsson]

May relate to https://github.com/MicrosoftEdge/WebView2Feedback/issues/2398 ?

[sigmarsson]

App running :

'X' =>

however the webview related processes seem to have deceased, only the parent proc remains dormant.

[JesseCol]

Hi @sigmarsson -- your scenario doesn't seem to involve RuntimeBroker (like @Sergio0694 is seeing), is that correct?

Can you explain what the "x" process is in your screenshot?

Also, can you check to see if the behavior here is the same when running under a debugger vs not? Thanks!

[sigmarsson]

@JesseCol , yes correct.

x is the WinUI application process.

It is the same. Either way, packaged and deployed or launched by VS debugger. x terminates now just because I employed the sledge hammer in public void Dispose as Environment.Exit.