Bug #175
WGI causes Cemu to fail to fully close; must be closed by using Task Manager > Details
Description
This should be a rather well-known problem at this point, and the reason I'm writing this is simply because it's a rather frequent problem in the community.
Upon a crash or a freeze in the emulator, due to personally unknown circumstances, after closing the emulator it seems to close, but in reality it still crashes. These instances of Cemu often get stuck in the background and do not fully close; this inevitably results in shaderCache being unreadable by the next open Cemu instance, in addition to users being unable to move or edit certain files. As for troubleshooting concerns, this also prevents future Cemu instances to write to the Log.txt so we can troubleshoot possible issues -- it results in us taking magnitudes longer to try and find the solution to a problem when the user is unfamiliar with Task Manager or has no idea why the Log is empty.
Often, Cemu will not appear in the main Task Manager [Processes] tab, as Windows may already consider it closed. It seems the process in [Details] is still there, however. This isn't always the case.
A few things could be done..
Upon opening a new Cemu instance, it closes any extra instances in the background.
However, doing this may cause problems for people who want to run 2 instances.
A workaround is to have a pop-up state "There is another Cemu instance running, would you like to close it to prevent problems?"Another method is to have Cemu write to a file showing that it successfully closed during the last session.
If it didn't successfully close, it would automatically close any extra instances in the background.
As it would ignore users opening two instances since the file would state it was already okay, this should prevent problems.Ideally, simply make it to where Cemu, for absolute certainty, closes even if a crash or other issue occurs.
The other earlier methods are potential fail-safes on the off-chance it still occurs due to a new bug or issue in the future.
Hopefully this could be fixed sooner than later so both the "my cache isn't loading with this new version of Cemu", "my log is empty", and "I just lost 5 hours of save data" questions may cease.
History
Updated by Laf111 over 4 years ago
If I can add a few words :
To me, the best way should be
- check if a Cemu.exe is already running
- if found, get using its command line the install's path
- compare to the current working dir
- if this installation of CEMU is already running (same working directories)
- pop-up "This installation of CEMU is already running in the background : close-it and continue? / Abort?
This solution allows running 2 instances of CEMU at the same time (but not sharing files)
Updated by Petergov over 4 years ago
- Status changed from New to In Progress
This issue should only occur while using cemuhook, but it should be fixed in 1.15.16
Updated by hexaae about 3 years ago
I don't use cemuhook, but with 1.22.10b I can say it still happens randomly that for example closes its UI on cache verify/generation at startup and then a CEMU.exe task gets stuck silently in background in the list of running apps, locking also audio device and preventing PC Sleep mode on idle...
Updated by Serfrost about 3 years ago
- Subject changed from Cemu getting stuck in the background, having to be closed by using Task Manager Details Tab to WGI causes Cemu to fail to fully close; must be closed by using Task Manager > Details
- Category changed from General to Input
- Status changed from Resolved to In Progress
- Cemu Version set to 1.22.11
From what we know this is caused (at least in part) by WGI - the Windows Gaming Input implementation for controllers - but we're unsure of what is specifically causing it. It will be looked into given some time.