Emulator Issues #13897
openDolphin Emulator Hanging on Close Button – ROG Ally (Build 2506-155 / 2509)
0%
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.
Updated by Billiard26 5 months ago
Please see if the situation is changed in 2509-109 or later.
Updated by Billiard26 5 months ago
· Edited
Please see if the issue is resolved in 2509-188.
https://dolphin-emu.org/download/dev/e8d9c124e5290c9c02c16d83583ce82b4e57c0f2/
Updated by hehk1234 4 months ago
Billiard26 wrote in #note-4:
Please see if the issue is resolved in 2509-188.
https://dolphin-emu.org/download/dev/e8d9c124e5290c9c02c16d83583ce82b4e57c0f2/
Didn't solved. I tried 258 too, but no success.
Updated by Billiard26 4 months ago
Updated by hehk1234 4 months ago
Billiard26 wrote in #note-6:
Please test: https://dl.dolphin-emu.org/prs/cb/0e/pr-14058-dolphin-latest-x64.7z
Same issue
Updated by Ale_ax 3 months ago
hehk1234 wrote:
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.
same issue from 2509, rog ally, z1 extreme windows 11
Updated by MonsterKeebler about 2 months ago
Save the below as a .bat script and run it to terminate dolphin.exe, forcefully closing it.
@echo off
REM ==========================================
REM Script to terminate Dolphin.exe if running
REM ==========================================
set "PROCESS_NAME=Dolphin.exe"
echo Checking for %PROCESS_NAME%...
REM Check if the process is running
tasklist /FI "IMAGENAME eq %PROCESS_NAME%" | find /I "%PROCESS_NAME%" >nul
if errorlevel 1 (
echo %PROCESS_NAME% is not running.
goto :EOF
)
REM Kill the process forcefully
echo Terminating %PROCESS_NAME%...
taskkill /IM "%PROCESS_NAME%" /F >nul 2>&1
if errorlevel 1 (
echo Failed to terminate %PROCESS_NAME%.
) else (
echo %PROCESS_NAME% has been terminated successfully.
)
pause
If you don't want the black CMD window to stay open you can delete the ending of the code and save it, and it will just auto close Dolphin.exe - revised code is below:
@echo off
REM ==========================================
REM Script to terminate Dolphin.exe if running
REM ==========================================
set "PROCESS_NAME=Dolphin.exe"
echo Checking for %PROCESS_NAME%...
REM Check if the process is running
tasklist /FI "IMAGENAME eq %PROCESS_NAME%" | find /I "%PROCESS_NAME%" >nul
if errorlevel 1 (
echo %PROCESS_NAME% is not running.
goto :EOF
)
REM Kill the process forcefully
echo Terminating %PROCESS_NAME%...
taskkill /IM "%PROCESS_NAME%" /F >nul 2>&1
How it works:
tasklist checks if Dolphin.exe is running.
If found, taskkill /IM Dolphin.exe /F forcefully ends it.
Includes error handling so it won’t throw errors if the process isn’t found.
pause lets you see the result before the window closes.
Additionally, you can create a shortcut pointing to the .bat file (shortcut example path below) to pin it to the taskbar and make a nice new little "X" button which would be used to close dolphin, which is my current fix. I additionally gave it the giant red X icon so I can easily differentiate it from other files (located inside of the DLL at the path: %systemroot%\system32\shell32.dll)
shortcut path Example:
cmd /c "C:\Users\user\Documents\killdolphin.bat"
Hope this helps make things a little less painless until the issue is resolved.