COM library crash exposed when using TBB scalable memory allocation

On Windows 11, using Intel's TBB with file dialogs causes a crash. I believe it is due to how the COM library is initialized in Qt.

See attached code to reproduce. I have tested with oneTBB 2021.8.0 (https://github.com/oneapi-src/oneTBB/releases/tag/v2021.8.0).

In Debug configuration, an assert is hit as soon as a file dialog is closed (see debug-assert.png).

In Release configuration, continuously open and close a file dialog (alternating between an "Open File Dialog" and a "Save File Dialog") until the application crashes on a call to show a file dialog. It usually crashes after less than 50 iterations of opening and closing a dialog. The call stack is the following when the access violation is hit:

ntdll.dll!00007ffa8001ec3e() StructuredQuery.dll!StructuredQuery1::Solution::~Solution(void)
StructuredQuery.dll!StructuredQuery1::Solution::Release(void)
StructuredQuery.dll!StructuredQuery1::CStructuredQueryHelper::~CStructuredQueryHelper(void)
StructuredQuery.dll!StructuredQuery1::CStructuredQueryHelper::Release(void)
comdlg32.dll!CFileOpenSave::~CFileOpenSave(void)
comdlg32.dll!CFileOpenSave::`vector deleting destructor'(unsigned int)
comdlg32.dll!CFileOpenSave::Release(void)
qwindows.dll!00007ffa00382044()
qwindows.dll!00007ffa003823a4()
qwindows.dll!00007ffa00382301()
qwindows.dll!00007ffa00382ea4()
qwindows.dll!00007ffa00389fd3()
Qt6QuickDialogs2.dll!00007ffa504d3a4c()
Qt6QuickDialogs2.dll!00007ffa504d3cb1()
Qt6QuickDialogs2.dll!00007ffa504d8f11()
Qt6Core.dll!00007ff9fe75fb81()
Qt6Qml.dll!00007ff9ffc1bf4c()
Qt6Qml.dll!00007ff9ffb25099()
Qt6Qml.dll!00007ff9ffb25426()
Qt6Qml.dll!00007ff9ffb26da5()
Qt6Qml.dll!00007ff9ffa8f423()
Qt6Qml.dll!00007ff9ffb3de73()

Note that no crash occurs when TBB is not used, or on Windows 10 (with or without TBB). However, I think that TBB only exposes the bug and is not the cause of it.

After some investigating, I found that the following work-around prevents the crash: in the main function of the application, make a call to initialize the COM library for multi-threaded concurrency before creating the QApplication object (i.e. call CoInitializeEx(nullptr, COINITBASE_MULTITHREADED)). That COM library initialization then supersedes the one made in the main thread in Qt (i.e. OleInitialize(nullptr) in the QWindowsContextPrivate constructor in qwindowscontext.cpp) and seems to work around the bug.
(note that this then triggers an error in void QWindowsNativeFileDialogBase::close(), which does however not have any consequence on Windows 11 as far as I can see)

The work-around also gets rid of the debug assert in TBB.

My understanding of COM library initialization (https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-coinitializeex) is that it should be initialized in each thread that uses COM objects. However, in Qt, it only seems to be initialized in the thread creating the QApplication object, and this for single-threaded concurrency.
The QWindowsDialogThread class (in qwindowsdialoghelpers.cpp) makes use of COM objects, on a different thread to the one that initializes the COM library.

My suspicion is therefore that the COM library is incorrectly initialized in Qt, and that leads to a bug that is somehow only exposed when using a third-party allocator.

Finally, I should point out that the crash can also be reproduced using the QFileDialog widget, by reusing the same QFileDialog object instead of creating a new one each time a file dialog is opened.