Crash in swap chain during shutdown due to teardown order #7924
Comments
ghost
added
the
|
@ackh In lieu of a repro, can you provide the complete dump? Or download as many symbols as possible, to improve the stack? Also, you might try the workaround in this issue, in case it's related: |
|
@Scottj1s Thanks for your reply. I have symbolicated the above stack trace and it looks as shown below. In addition, the memory dump of that state is available here. |
|
@ackh Thanks - very helpful. Will pass this along to the appropriate owners. |
|
@gegao18 any ideas? |
|
Thanks for the stack trace. This looks like a known potential crash on shutdown when resources get torn down in a bad order, and it's something we're working on for WinAppSDK 1.3. Do you see this crash shortly after tearing down Xaml in your app or shutting it down? The workaround in this case would be disconnect the SwapChainPanel from the tree and making sure it's deleted before shutting down the rest of Xaml. |
|
@gegao18 Yes, I'm seeing it in both cases, i.e. when tearing down XAML that host a SwapChainPanel and when shutting down the app. If you need additional information to get to the bottom of this let me know. |
bpulliam
changed the title
|
@ackh The problem is understood and a solution is in the works Internal issue: task.ms/42283983 |
|
Fix will be available in Windows App SDK 1.3. Unfortunately, there is no known workaround. |
|
Thanks, @Scottj1s. I'm looking forward to 1.3! |
Does the fix in 1.3 potentially also cover #7254? It's particularly reproducible if tearing down a swapchain immediatley after setting one up |
I seem to have found a workaround for #7254, and given the issue title here, it seems likely it will also work here: DemoPage::DemoPage() noexcept {
InitializeComponent();
auto weakThis = get_weak();
mDQC = DispatcherQueueController::CreateOnDedicatedThread();
// Don't need a swapchain for crash, but do need independent input source
mDQC.DispatcherQueue().TryEnqueue([weakThis]() noexcept {
auto strongThis = weakThis.get();
if (!strongThis) {
return;
}
auto inputSource = strongThis->SwapChainPanel().CreateCoreIndependentInputSource(
InputPointerSourceDeviceKinds::Mouse | InputPointerSourceDeviceKinds::Pen
| InputPointerSourceDeviceKinds::Touch);
});
}
winrt::fire_and_forget DemoPage::final_release(std::unique_ptr<DemoPage> self) {
auto panel = self->SwapChainPanel();
// Delete 'self'...
self.reset();
// Literally delay deletion of `panel`. 0 doesn't fix the crash, I think we just need
// to have re-entered the message pump/event loop
co_await winrt::resume_after(std::chrono::milliseconds(1));
co_return;
}This is working fine when navigating 100 times in a loop; previously it would reliably crash on iteration 2. |
|
@Scottj1s @gegao18 I have retested this bug with release 1.3.230331000 and I'm now getting the following crash and call stack: I would really appreciate if someone could look into this soon. It might be an issue that I cause, but how would I know? |
|
@ackh I am also facing the exact same issue. Kindly re-open the issue. |
|
@ackh The engineer working on the second crash reported here has requested another dump:
Would you be able to provide one? |
|
Sure, the dump is available here. I'm trying to put together a DirectX sample that uses the SwapChainPanel the same way as my production code. I'm currently not sure how feasible that is but it would likely help in the future in case we encounter other issues related to the SwapChainPanel. |
This commit adds the code that is necessary to react on mouse, pen and touch events. However, it does not actually execute code when such an event occurs. It was purely added to reproduce the issue described in [1] which occurs as soon as the version of the Windows App SDK NuGet packages is raised to a version > 1.1.5 and <= 1.3.230602002. [1]: microsoft/microsoft-ui-xaml#7924
This commit enables reproducing the issue described in [1]. [1]: microsoft/microsoft-ui-xaml#7924
|
@Scottj1s I managed to create a sample with which the issue can be reproduced. This GitHub repository contains the code. A few words regarding the content of the repository: The code added by commit
In that state, clicking the "Square View" button destroys the view showing the triangle and then creates the view that is showing a rectangle:
This is the expected behavior. If the app is started from Visual Studio with the debugger attached, closing the app will result in an exception and the hint that there are memory leaks. That seems to be the case because the code enables the DirectX debug layer and terminating the app does not properly clean up the DirectX resources. That app behavior might need to be discussed in another thread but for the time being, it is prevented by commit Following on, commit Finally, commit Could you notify the responsible developer about this sample? I can reproduce it 100% of the time so it should be straight forward to find and fix the actual root cause. |
|
@ackh the team believes the last issue related to swap chain teardown crashes was addressed in Windows App SDK 1.3.230724000. Can you please re-evaluate with that or a later version? |
|
@ackh, I have been testing this issue with every release of the WinAppSDK. I can confirm that the crash issue is no longer reproducible in any of the releases starting from 1.3.230724000 upto the latest 1.4.231008000 But there is another major issue. See video attached SCP.Issue.mp4SwapChainPanel resizing is extremely laggy with discrete graphics involving the PCIE bus for release builds. No issue with Debug builds :-) I have a Intel integrated GPU + NVDIA GPU active on the system with Intel configured in SBIOS as the default display. If i disable the Intel Integrated GPU completely in SBIOS then also the issue is present. This issue has been there since the begining. Across the different releases of WinApp SDK since 1.3.230724000, I have tried all possible things including changing the NVIDIA driver version I guess there is a bug hiding in the release build of the SDK and it has something to do with the lifted compositor in WinUI 3. I have lost the motivation for filing new issue. I am migrating my app back to Win32 :-( |
Upgrading to version 1.4.231008000 of the Windows App SDK resolves the issue described in [1] which, according to the release notes, was originally fixed in version 1.3.230724000. [1]: microsoft/microsoft-ui-xaml#7924 [2]: https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/stable-channel#version-133-13230724000
Describe the bug
I have an app that uses custom controls that inherit from SwapChainPanel to render DirectX content. Each custom control is shown on a dedicated page within a NavigationView. Switching the page in the NavigationControl destroys the previously shown SwapChainPanel-based control and creates an instance of the control to be shown.
Switching between the NavigationView pages worked fine when using the Windows App SDK 1.1.5 or earlier. However, after upgrading to the Windows App SDK 1.2 I'm getting an unhandled exception when the following method of Microsoft.UI.Xaml.h is called:
That exception simply states the following:
The full stack trace looks as follows:
The problem I have is that I'm currently clueless how that stack trace is related to my own code because none of the code in the call stack is mine. How can I figure out what the actual problem is?
As mentioned, this behavior only occurs when using Windows App SDK 1.2. What has changed there that now raises such an exception compared to the Windows App SDK 1.1.5 and earlier?
Steps to reproduce the bug
Currently only reproducible in proprietary code.
Expected behavior
If such an exception is thrown there should be a hint what the underlying issue is. It's not obvious what is causing this.
Screenshots
No response
NuGet package version
WinUI 3 - Windows App SDK 1.2.0
Windows version
Windows 10 (21H2): Build 19044
Additional context
The following NuGet packages are used:
Microsoft.Windows.CppWinRT.2.0.220909.4
Microsoft.Windows.SDK.BuildTools.10.0.22000.196
Microsoft.WindowsAppSDK.1.1.5
The text was updated successfully, but these errors were encountered: