qwindows.dll: QWindowsContext::windowsProc() is invoked after the destructor ~QWindowsContext has already started (use-after-destroy), when a broadcast message WM_DEVICECHANGE arrives during application shutdown.

Added to code (for diagnostics)

QWindowsContext::~QWindowsContext()
{
logSimple("~QWindowsContext");
...
}
bool QWindowsContext::windowsProc(HWND hwnd, UINT message,
QtWindows::WindowsEventType et,
WPARAM wParam, LPARAM lParam,
LRESULT *result,
QWindowsWindow **platformWindowPtr)
{
if (QWindowsIntegration::instance() == nullptr) {
logSimple("QWindowsIntegration::instance()");
logDeviceChange(hwnd, message, wParam, lParam);
return false;
}
}

Log fragment

[14:35:59.359] ~QWindowsContext
[14:35:59.361] QWindowsIntegration::instance() == nullptr // inside windowsProc()
================== DEVICE EVENT ==================
message : 0x0219 (WM_DEVICECHANGE)
wParam : 0x0007 (DBT_DEVNODES_CHANGED)

Details

During application shutdown, Windows may still broadcast system-wide messages.
One of them (WM_DEVICECHANGE) can reach qWindowsWndProc, which then calls
QWindowsContext::windowsProc() even though the QWindowsContext object is already being destroyed.
This results in a potential use-after-free inside qwindows.dll.

Reproducibility

This issue is intermittent and does not reproduce on every run or device.
In my tests, it happens roughly once in 1000 application launches.
I repeatedly start the same Qt GUI application via an automation script, and sometimes —
when I connect/disconnect a USB mouse or toggle a monitor during shutdown — the crash occurs.

It appears to be a race condition, where windowsProc() is invoked
after ~QWindowsContext() has already begun execution.
The only reliable way to trigger it so far is to run many start/exit cycles
while connecting or disconnecting devices in parallel.