Project

General

Profile

Actions

Emulator Issues #13897

open

Dolphin Emulator Hanging on Close Button – ROG Ally (Build 2506-155 / 2509)

Emulator Issues #13897: Dolphin Emulator Hanging on Close Button – ROG Ally (Build 2506-155 / 2509)

Added by hehk1234 11 months ago. Updated 7 months ago.

Status:
New
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
Windows
Issue type:
Bug
Milestone:
Regression:
Yes
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
2506-155
Fixed in:

Description

Hello Dolphin Developers,

I am reporting a reproducible issue affecting the Dolphin emulator on the ROG Ally device. The problem occurs when attempting to close the emulator window using the “X” button. The emulator hangs indefinitely and can only be terminated via Task Manager.

Issue Summary:

Affected Builds: 2506-155 (“SDL3 update”) and 2509 (Qt6.7+)

Working Builds: 2506 pre-155, 2507/2508 dev builds with Qt6.6.x

Platform: ROG Ally, Windows 11, touchscreen device

Observed Behavior:

Clicking “X” does not close the emulator.

Task Manager shows Dolphin.exe with a thread stuck (example: Thread 3424).

Issue does not reproduce on standard desktop PCs without touchscreen.

Investigation:

Thread dump analysis shows the following stack trace for the blocked thread:
win32u.dll!NtUserMsgWaitForMultipleObjectsEx+0x14
combase.dll!CoWaitForMultipleHandles+0xb24
combase.dll!InternalRegisterWindowPropInterface2+0x3cc
combase.dll!CoUnmarshalInterface+0x5dfd
Dolphin.exe+0xd2f351
Dolphin.exe+0xc94736
Dolphin.exe+0xc9c161
...
Qt debug logs indicate that the Qt platform plugin windows is loaded successfully, but the deadlock occurs during COM calls related to window property registration for touch input.

The issue seems to be triggered by the SDL3 update in 2506-155, in combination with Qt6.7+ and the ROG Ally’s WinRT touchscreen environment.
Key Points:

The deadlock occurs in CoWaitForMultipleHandles inside combase.dll, indicating a COM call never returns while Qt tries to destroy the window.

Workarounds via .bat parameters (QT_NO_NATIVE_WINDOWS, QT_NO_WINRT, QT_NO_GESTURES, QT_USE_DIRECT2D=0) did not resolve the issue.

Renaming SDL3.dll or forcing software rendering in Qt does not fully fix the hang due to internal SDL3 + Qt6 COM interactions.

Logs:

Attached is a snippet from my log (qt_log.txt) capturing the initialization and platform plugin load sequence, showing the Qt6 and Direct2D/Windows integration:
qt.qpa.plugin: init_platform called with pluginNamesWithArguments "windows" platformPluginPath "" platformThemeName ""
qt.core.plugin.factoryloader: looking at "C:/Users/celso/Downloads/Compressed/dolphin-2509-x64/Dolphin-x64/QtPlugins/platforms/qdirect2d.dll"
qt.core.plugin.loader: Found metadata ... "direct2d"
qt.core.plugin.factoryloader: looking at "C:/Users/celso/Downloads/Compressed/dolphin-2509-x64/Dolphin-x64/QtPlugins/platforms/qwindows.dll"
qt.qpa.plugin: Attempting to load Qt platform plugin "windows"
qt.qpa.window: QWindowsContext::setProcessDpiV2Awareness
qt.qpa.events: Digitizers: 0x41 Ready: 0x80 Tablet PC: 1 Max touch points: 10
qt.qpa.window: QWindowsContext::registerWindowClass "Qt651PowerDummyWindow" ...
qt.qpa.plugin: Successfully loaded Qt platform plugin "windows"
qt.qpa.theme: Successfully created platform theme "windows"
Conclusion:

The issue is not present in desktop environments without touchscreen.

The deadlock is introduced in builds with SDL3 + Qt6.7+, and specifically affects devices with WinRT touch + DPI per-monitor awareness.

A potential fix may involve reverting SDL3 changes or adjusting Qt6 COM handling for touch input on hybrid devices.

Please let me know if additional logs, memory dumps, or thread dumps are required for deeper investigation.

Thank you for your time and support.

Actions

Also available in: PDF Atom