-
Notifications
You must be signed in to change notification settings - Fork 706
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
App crashes when exiting an app that uses MenuBar and WebView2 #7260
Comments
@osamu-ikawa This is a weird one. Although your instructions were very clear (thanks!), I couldn't repro this on my own. I wouldn't expect any particular interaction between WebView2 and MenuBar that would cause an issue. Can you tell me what version of the WebView2 Runtime you have on your machine? You can find this in the list of installed apps in settings. If you have a Dev/Canary/Beta channel Edge installed, please let me know. You could try calling Close() on the WebView2 before you remove it from the UI, that might help. Although it shouldn't be required, it is best practice to Close() webviews when you're done with them. |
Edge And WebView2 Runtime versionEdge: 102.0.1245.44 I don't have Dev/Canary/Beta channel Edge. Calling Close() before removing WebView2I updated the
However, a crash occurred when the app was closed. Additional InformationI had this problem even if I replaced MenuBar with CommandBar.
After clicking the Open button on the CommandBar twice, a crash occurred when I quit the app. Sometimes issue is not reproduced, but I don't know the conditions. |
This is the result of analyzing the crash dump by WinDbg. I hope this helps.
|
The reason behind this crash is calling into threadpoolwinrt.dll when it is already freed. On process shutdown, dlls are unloaded in reverse order. As threadpoolwinrt.dll is loaded later than Microsoft.Ui.Xaml.dll, it gets unloaded first. During unload, it sets Here's a stack trace when this happens:
Followed by this,
However, This means this crash will occur any time there are two or more references to the ThreadPoolTimer interface, opened from dlls that were loaded earlier and destroyed in their destructors. Xaml keeps one on its own by default, while initializing WebView will cause a second reference, therefore fulfilling the requirements for a crash. I created a simple C++ program and library to recreate this issue in a cleaner environment: Dll1.cpp// compile as dll
#include <windows.h>
#include <roapi.h>
#include <cstdio>
#include <vector>
#include <windows.system.threading.h>
#pragma comment(lib, "windowsapp.lib")
GUID GUID_1a8a9d02_e482_461b_b8c78efad1cce590 = { 0x1a8a9d02, 0xe482, 0x461b, { 0xB8, 0xC7, 0x8E, 0xFA, 0xD1, 0xCC, 0xE5, 0x90 } };
std::vector<IUnknown*> tpts;
constexpr static size_t how_many = 2; // Set to 1 to avoid crash
struct IHaveADestructor
{
IHaveADestructor() = default;
~IHaveADestructor()
{
for (const auto tpt : tpts)
tpt->Release();
}
};
IHaveADestructor asdasdsa;
__declspec(dllexport) int do_stuff()
{
RoInitialize(RO_INIT_MULTITHREADED);
HSTRING hs;
WindowsCreateString(
L"Windows.System.Threading.ThreadPoolTimer",
wcslen(L"Windows.System.Threading.ThreadPoolTimer"),
&hs);
for (size_t i = 0; i < how_many; ++i)
{
IUnknown* tpt{};
const auto hr = RoGetActivationFactory(
hs,
GUID_1a8a9d02_e482_461b_b8c78efad1cce590,
(void**)&tpt
);
if (!tpt)
{
printf("shits broken! %08X\n", hr);
return -1;
}
tpts.push_back(tpt);
}
return 0;
}
BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)
{
return TRUE;
} main.cpp// link against the earlier dll
extern int do_stuff();
int main()
{
do_stuff();
return 0;
} Setting Unfortunately I couldn't come up with a simple workaround, so fixing this is mostly on Microsoft. The most obvious fix would be not calling |
I posted a workaround in C# / MAUI for this: dotnet/maui#7317 (comment) |
@namazso |
@namazso, your analysis is spot-on, thank you. The fix is simply to let the global threadpool factory objects "leak" at app shutdown (which of course, the OS will clean up) - as also recommended by Raymond Chen. |
Fix is now available: https://www.nuget.org/packages/Microsoft.WindowsAppSDK/1.2.230118.102 |
Describe the bug
In an app that uses MenuBar and WebView2, if you exit the app after performing the following processing, an access violation will occur.
An access violation occurs when the "exit" function is called in "exe_common.inl".
This issue only occurs in Windows App SDK 1.1.X and not in 1.0.3.
Steps to reproduce the bug
This problem is reproduced with a very simple code.
MainWindow.xaml
MainWindow.idl
MainWindow.xaml.h
MainWindow.xaml.cpp
Expected behavior
No error occurs when exiting the app.
Screenshots
NuGet package version
WinUI 3 - Windows App SDK 1.1.1
Windows app type
Device form factor
Desktop
Windows version
Windows 10 (21H2): Build 19044
Additional context
This issue does not occur if you edit the code as one of the following:
Holder().Children().Clear()
.)EnsureCoreWebView2Async
. (Comment out the contents of theShowWebsite
function.)<Button Grid.Row="0" Click="OpenButtonClick">Open</Button>
The text was updated successfully, but these errors were encountered: