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 5 months ago. Updated about 2 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.

Updated by JosJuice 5 months ago Actions #1

  • Regression changed from No to Yes
  • Regression start set to 2506-155
  • Operating system Windows added
  • Operating system deleted (N/A)

Updated by Billiard26 5 months ago Actions #2

Please see if the situation is changed in 2509-109 or later.

Updated by hehk1234 5 months ago Actions #3

Billiard26 wrote in #note-2:

Please see if the situation is changed in 2509-109 or later.

In any version below 159, the close button works without any problems.

Updated by Billiard26 5 months ago · Edited Actions #4

Updated by hehk1234 4 months ago Actions #5

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 hehk1234 4 months ago Actions #7

Updated by Trace6x 4 months ago Actions #8

Hello I would just like to add I am also having this issue

Updated by Ale_ax 3 months ago Actions #9

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 Ale_ax 3 months ago Actions #10

same issue from 2509 with Rog Ally z1 extreme

Updated by MonsterKeebler about 2 months ago Actions #11

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.

Actions

Also available in: PDF Atom