MO2 process stuck on exit

[therob]

System Information

• SteamTinkerLaunch version: v12.12
• Distribution: Ubuntu 20.04 LTS
• Installation Method: ProtonUp-Qt

Issue Description

I'm currently trying to mod Fallout 4 with MO2.
The MO2 process does not exit after closing the UI and needs to be killed via Steam. Also the details view of a mod in MO2 (double-clicking an installed mod) just opens a window with black content and then the process completely freezes. Disabling the Wine theme does not fix this.
This only happens in Game Mode. Standalone mode works fine. I'm using GE-Proton8-3 to run MO2 in both modes.

Workaround

Using GE-Proton7-55 in Game Mode fixes this issue completely (hanging on exit and the details view). For me, this also requires disabling the Wine theme to fix the Glitchy UI issue.
-- or --
Using GE-Proton8-3 and disabling Steam Linux Runtime (SLR) also solves this.

Logs

There is nothing obvious in the logs. Comparing the logs between Standalone an Game Mode also shows nothing suspicious. I tried setting the logging in MO2 to the highest level, but this shows nothing when it happens.
I guess wine logging could help here, but I'm not sure what logging category to enable and full logging usually creates a lot of log spam. If you have any idea which logging categories could help, then I'm happy to try it again and provide the logs.

[sonic2kk]

I guess STL could attempt to force kill MO2 on exit, but what is the issue for SteamTinkerLaunch here? Am I misunderstanding here or is this solely an issue when using a build of GE-Proton8-X (may affect other builds of Proton which use Wine 8) that is fixed by using GE-Proton7-55 (may also work with builds of Proton which use Wine 7)?

If this is the case then I don't think this is a bug on the SteamTinkerLaunch side.

The MO2 process does not exit after closing the UI and needs to be killed via Steam. Also the details view of a mod in MO2 (double-clicking an installed mod) just opens a window with black content and then the process completely freezes

What you've described here seems like a Wine bug. One user reported issues with MO2 on builds of Proton which use Wine 8+ (#805). However the other issue:

This only happens in Game Mode. Standalone mode works fine. I'm using GE-Proton 8.3 to run MO2 in both modes.

If this process freeze, in both MO2 modes, is fixed with GE-Proton7-55 as you described (if I understood correctly), then this is a Wine issue and not a SteamTinkerLaunch issue.

This crash happening in Game Mode may be some issue with running MO2 in the game prefix. I'll see if I can reproduce the crash later.

For me, this also requires disabling the Wine theme to fix the Glitchy UI issue.

This is because Wine 8 uses a different default theme and Proton builds using Wine 8 use a newer Wine-Mono which is more compatible.

I guess wine logging could help here, but I'm not sure what logging category to enable and full logging usually creates a lot of log spam. If you have any idea which logging categories could help, then I'm happy to try it again and provide the logs.

I don't remember if MO2 shows any Wine logging. If it doesn't, you could try mimicking the launch command that MO2 uses. I am mainly interested in this crash when using Game Mode, in case there is some config file missing that isn't symlinked, but if this only happens with Proton 8+ then I think this is a Wine issue and not an STL issue.

Just for clarity as some users have made this mistake before: I don't develop MO2, and STL doesn't download any kind of custom MO2 version. It installs MO2 into a standalone prefix, and does some extra spice to help manage game instances by using symlinks and custom launch flags for MO2. But there is no extra work done with Wine or MO2. Bugs that arise from using MO2 under Wine are not directly STL bugs. If there turns out that there may be a missing component to help XYZ part of MO2 it can be added, but Wine bugs are not something I can fix unfortunately. Still, I'm not against discussing and documenting these issues, but I wanted to clear up that I'm not affiliated with MO2 and similarly MO2 devs don't guarantee Wine compatibility.

[sonic2kk]

Just tested MO2 in Game Mode and GUI mode with both the standard "none" theme and the "Paper Automata" theme I usually use, with Proton 8.0-2d, and MO2's mod info dialog is working fine. I tested with my Oblivion and New Vegas mod installations.

I did notice that sometimes when it first opens (in Game Mode and Standalone Mode) that it is a blank window for a few seconds.

---

Something that occured to me is that I wonder if this is related to Wine libraries, as this has been the case with a small handful of third-party programs running under Wine, but I don't think this is the case. You could try disabling the Steam Linux Runtime and seeing if the crash is resolved, as this is the only other main difference I can think of between Standalone Mode and Game Mode (Game Mode is the only one that would use the SLR).

Another potential cause could be related to locales or characters in a mod name/file that MO2 can't render, but I don't know why this would only happen in Game Mode.

There is what I believe to me a very small chance that this could be a graphics driver problem, but I really doubt that it would be the case.

[therob]

I guess STL could attempt to force kill MO2 on exit, but what is the issue for SteamTinkerLaunch here? Am I misunderstanding here or is this solely an issue when using a build of GE-Proton8-X (may affect other builds of Proton which use Wine 8) that is fixed by using GE-Proton7-55 (may also work with builds of Proton which use Wine 7)?

Killing MO2 is more a workaround in my opinion. I think this should be the last resort.
Sorry if i wasn't clear with the issue. What got me the idea that SteamTinkerLaunch could somehow cause the problem is the following:

• MO2 in Standalone Mode with GE-Proton8-3: no problem ✔️
• MO2 in Game Mode with GE-Proton7-55: no problem ✔️
• MO2 in Game Mode with GE-Proton8-3: MO2 process gets stuck ❌

So my guess was, that it has something to do with how MO2 is started or installed in Game Mode.

And what i mean with "process stuck" is that the MO2 UI closes but the process keeps running and starts using up 100% of one CPU core.
I also noticed, that killing ModOrganizer.exe does not stop some other Wine processes (like explorer.exe, winedevice.exe and others). And one of two winedevice.exe processes needs to be killed with SIGKILL, for all other SIGTERM works.

Just for clarity as some users have made this mistake before: I don't develop MO2, and STL doesn't download any kind of custom MO2 version. It installs MO2 into a standalone prefix, and does some extra spice to help manage game instances by using symlinks and custom launch flags for MO2. But there is no extra work done with Wine or MO2. Bugs that arise from using MO2 under Wine are not directly STL bugs. If there turns out that there may be a missing component to help XYZ part of MO2 it can be added, but Wine bugs are not something I can fix unfortunately. Still, I'm not against discussing and documenting these issues, but I wanted to clear up that I'm not affiliated with MO2 and similarly MO2 devs don't guarantee Wine compatibility.

I'm fully aware of that. I'm following this project for a long time now and looked through the code a few times if i had any questions or problems. As i already had a workaround, i just wanted to bring it up and see if anything can/should be done on the STL side.

You could try disabling the Steam Linux Runtime and seeing if the crash is resolved, as this is the only other main difference I can think of between Standalone Mode and Game Mode (Game Mode is the only one that would use the SLR).

This is it. Disabling the Steam Linux Runtime fixed the issue.
So something has changed between GE-Proton7 and GE-Proton8 that makes it work in GE-Proton7 with SLR and GE-Proton8 needs SLR disabled for MO2.

[sonic2kk]

Killing MO2 is more a workaround in my opinion. I think this should be the last resort.

Is there any reason here? Out of laziness sometimes I will quit games this way from Steam instead of going through a bunch of menus. Just wondering if I'm missing something.

There are also a handful of games which don't close properly, particularly when using the SLR, and for Steam Deck games marked as playable Valve will even sometimes note that they have to be manually quit because they don't exit cleanly.

And what i mean with "process stuck" is that the MO2 UI closes but the process keeps running and starts using up 100% of one CPU core.
I also noticed, that killing ModOrganizer.exe does not stop some other Wine processes (like explorer.exe, winedevice.exe and others). And one of two winedevice.exe processes needs to be killed with SIGKILL, for all other SIGTERM works.

As you found out the SLR was the culprit here, I would say this is some combination of a Wine/SLR process, rather than SteamTinkerLaunch specifically, but thank you for clarifying. That does sound pretty nasty!

A while ago I used to run the Amazon Music app through Wine-GE on my machine and while it didn't have the CPU issue you described, it had the problem of needing to kill the various wineserver processes manually.

So my guess was, that it has something to do with how MO2 is started or installed in Game Mode.

From the cases mentioned, the fact that changing the Proton version would point to it being a Wine-related issue in my mind :-) Since the variable that breaks the behaviour here is the Proton version. However as it turns out it is not directly a Wine issue! 😄

This is it. Disabling the Steam Linux Runtime fixed the issue.

Proton 7 builds use a different runtime than Proton 8 builds. Steam Linux Runtime builds are named after Team Fortress 2 classes. The native Linux runtime is Scout, Proton5-X through Proton 7-X use Soldier, and Proton 8 builds have started using Sniper. My guess, then, is that there is an incompatibility with this runtime and MO2. The strange thing is that it works fine on two different machines that I have (albeit they both run the same distro with the same DE). It could be a mix of the SLR and Proton build having some incompatibility, debugging issues like this is not something I have any experience in and wouldn't know where to start so I'm afraid I can't really say what might be going wrong.

I will also note that disabling the SLR may fix the issue but this may cause issues with games, as Proton is meant to be used with the Steam Linux Runtime. Each Proton version has a toolmanifest.vdf file in its folder which specifies a require_tool_appid. This AppID, in the case of Proton, corresponds to a required Steam Linux Runtime version.

As i already had a workaround, i just wanted to bring it up and see if anything can/should be done on the STL side.

Which is a good thing to do. I clarified that MO2 wasn't made by me as a few users have gotten the wrong idea :-)

I don't think much else can be done, as the SLR is usually very important to use, but STL has a toggle for it so I hope that can help resolve the issue at least for now. As far as I can tell from this, the issue is to do with Steam Linux Runtime Sniper (AppID 1628350). I don't think there is a clean way for STL to launch MO2 without the SLR but then get it to launch MO2 games with the SLR, since MO2 is responsible to launching its own processes e.g. the game process. You may be able to build an SLR launch command to feed to MO2, or get it to launch a script that launches the executable with the SLR, but since MO2 is a Wine process I don't know how that would work out.

---

I guess in the end the solution here will be to either disable the SLR, or use an older Proton build. This problem could be resolved with an update to the Steam Linux Runtime or a future Proton version. If you haven't already, you could try a build of Valve's Proton such as Proton Experimental or Proton 8.0 and see if that works more reliably with the SLR (though I wouldn't hold my breath).

Thanks for reporting, not sure exactly how we want to proceed here though 😅 If you're happy we can close the issue or if there's anything further you think STL should do please let me know :-)

P.S.

I'm following this project for a long time now and looked through the code a few times if i had any questions or problems

Nice to see an STL "veteran" for once 😄

[therob]

Is there any reason here? Out of laziness sometimes I will quit games this way from Steam instead of going through a bunch of menus. Just wondering if I'm missing something.

This is mostly the developer in me that cries here. 😅 Killing a process always has a chance to cause problems with files currently open for writing. In the worst case it can corrupt saves or cache files, which can cause new problems.
Also there is a reason for this to happen. So this is the problem that should be fixed. But analyzing these problems can also take a lot of effort. It is often hard to decide when to fix a problem properly and when to use a workaround.
In this case, just killing MO2 would leave some wine processes running. I guess stopping through Steam is smarter as it stops all processes reliably.

Proton 7 builds use a different runtime than Proton 8 builds. Steam Linux Runtime builds are named after Team Fortress 2 classes. The native Linux runtime is Scout, Proton5-X through Proton 7-X use Soldier, and Proton 8 builds have started using Sniper. My guess, then, is that there is an incompatibility with this runtime and MO2. The strange thing is that it works fine on two different machines that I have (albeit they both run the same distro with the same DE). It could be a mix of the SLR and Proton build having some incompatibility, debugging issues like this is not something I have any experience in and wouldn't know where to start so I'm afraid I can't really say what might be going wrong.

This is good to know. I have seen the different builds before. But now i understand better how this ties into Proton.
Just an idea: From what i have seen while looking into STL and the Proton script, it seems a bunch of behavior is controlled by environment variables. Maybe Sniper needs something set additionally or different. Something that doesn't cause problems in most cases, just here with MO2. But somehow I also have a feeling that usvfs has something to do with this.

I will also note that disabling the SLR may fix the issue but this may cause issues with games, as Proton is meant to be used with the Steam Linux Runtime.

Yeah, disabling SLR is still a workaround. I guess Fallout 4 is old enough and Ubuntu "standard" enough that it works in this case with plain Proton.

I don't think there is a clean way for STL to launch MO2 without the SLR but then get it to launch MO2 games with the SLR, since MO2 is responsible to launching its own processes e.g. the game process. You may be able to build an SLR launch command to feed to MO2, or get it to launch a script that launches the executable with the SLR, but since MO2 is a Wine process I don't know how that would work out.

I don't know if it is even possible. As Proton/Wine is launched within SLR (or the native runtime), this would basically require a process within Wine to start another process in a different Wine runtime environment.

I guess in the end the solution here will be to either disable the SLR, or use an older Proton build. This problem could be resolved with an update to the Steam Linux Runtime or a future Proton version. If you haven't already, you could try a build of Valve's Proton such as Proton Experimental or Proton 8.0 and see if that works more reliably with the SLR (though I wouldn't hold my breath).

I will probably test this again when a new version of something involved drops (if i remember to do so 😆 ) and leave a comment.

Thanks for reporting, not sure exactly how we want to proceed here though 😅 If you're happy we can close the issue or if there's anything further you think STL should do please let me know :-)

That's fine for me. I will close this issue here. At least the problem is documented and you have heard of this situation. There is always the possibility that something similar will pop up in future.

Anyway, thanks for your support with this. 👍

P.S.

Nice to see an STL "veteran" for once 😄

Calling me a "veteran" might be bit much. 😆 At the moment I'm only using it to run Vortex and now MO2 for a few games. But I'm glad this project exists and is still alive.
Also I have seen in some issues that you and a few others were thinking out loud about a rewrite. Feel free to ping me if that happens. I might be able to help out. My experience is primarily in Java but i can deal more or less with most languages.

[sonic2kk]

This is mostly the developer in me that cries here. 😅 Killing a process always has a chance to cause problems with files currently open for writing. In the worst case it can corrupt saves or cache files, which can cause new problems.
Also there is a reason for this to happen. So this is the problem that should be fixed. But analyzing these problems can also take a lot of effort. It is often hard to decide when to fix a problem properly and when to use a workaround.
In this case, just killing MO2 would leave some wine processes running. I guess stopping through Steam is smarter as it stops all processes reliably.

Yeah, you're absolutely correct here. Killing a process is a bit dangerous, and indeed the core issue with MO2 should be fixed, but I think we're in agreement that the problem is more likely to do with Wine. If I figure out what might be causing it I could investigate further in the future, and maybe there is some trick STL could do to fix the problem (or even a step that could be documented).

This is good to know. I have seen the different builds before. But now i understand better how this ties into Proton.
Just an idea: From what i have seen while looking into STL and the Proton script, it seems a bunch of behavior is controlled by environment variables. Maybe Sniper needs something set additionally or different. Something that doesn't cause problems in most cases, just here with MO2. But somehow I also have a feeling that usvfs has something to do with this.

Yup, a lot of Proton is managed by environment variables. This is in part because the SLR is a container so having things as environment variables probably helps in that regard. Though I am not sure why the Proton script uses Python of all things (I like Python, just no idea around why that choice was made). The differences between the runtimes are, to my understanding, primarily the libraries it bundles. If you don't use the SLR, Proton will look at your system libraries to find what it needs to run (this is why Wine-tkg builds can be larger than Proton builds, as Wine builds bundle the required libs afaik). But there could be further configuration. I am not too familiar with the technology that Valve use for the SLR other than they have comically named it "pressurevessel" (because it's a Steam container, har-har) and it's based on Flatpak's "bubblewrap" (which is where the process name pv-bwrap comes from - Pressure Vessel Bubblewrap).

If you'd like to take a peak around how Sniper works, you can go to Steam -> Search for "Steam Linux Runtime" -> Right click on one -> Manage -> Browse local files. From here you can see three main scripts: _v2-entry-point (Steam and STL use this to launch applications), run, and run-in-[suite], where [suite] will change depending on "Soldier", "Sniper", etc. The entry point script will choose which of these to run afaik. Native Linux games use the plain Steam Linux Runtime, and the other ones with suffixes are used for Proton. A little bit of extra discussion around this happened in #806, you can also see the PR where this was implemented in #737 (eventually I'll need to get around to documenting this on the wiki...). The SLR is picked based on a require_app_id in a Proton version's toolmanifest.vdf file (i.e. Proton 8.0/toolmanifest.vdf). We get the path to the required SLR based on the AppID here (STL has code to find paths based on AppIDs) and then build a launch command based on this.

When pressing "Play" from SteamTinkerLaunch, the game launch command will always use the SLR if the option is enabled. This is why MO2 will use the SLR when running in Game Mode but not Standalone Mode. There are some other instances where the SLR is used as well; as of ddd4b3a, Vortex now uses the SLR to install itself because apparently this is required on SteamOS. It is not impossible that further changes like this may be required for MO2 on SteamOS, so I will keep in mind that the SLR can actually cause issues for MO2, or at least the latest Sniper can.

disabling SLR is still a workaround. I guess Fallout 4 is old enough and Ubuntu "standard" enough that it works in this case with plain Proton.

Agreed, I should probably note this on the wiki. Maybe I could add a general note on the modding wiki page that enabling/disabling the SLR may fix/cause issues, for users who don't know it even exists (I didn't know much about it until I had the true fortune of troubleshooting SLR issues 😉)

Proton is technically only meant for use with the Steam Linux Runtime, at least Valve Proton and GE-Proton, because it is built against the libraries in its Steam Linux Runtime (in this case, Sniper). But it seems that for MO2, the libraries Proton is built against are actually less compatible than the system libraries, which is unusual and pretty interesting!

I don't know if it is even possible. As Proton/Wine is launched within SLR (or the native runtime), this would basically require a process within Wine to start another process in a different Wine runtime environment.

Yup, I described essentially the same limitation in #798. If it's possible at all, I don't see it being clean 😅

I will probably test this again when a new version of something involved drops (if i remember to do so 😆) and leave a comment.

Feel free to, the SLR updates seemingly randomly in my experience anyway (it comes through as an update in my Steam downloads every so often), it could also be that newer Proton versions may have patches that resolve issues too (Proton-tkg based on Wine Master resolved an issue with Vortex missing a specific Wine component, see #792).

At least the problem is documented and you have heard of this situation. There is always the possibility that something similar will pop up in future.

Yeah as you've probably seen from this reply alone, I like to reference other issues and PRs during discussions, so if something related to this comes up I can go "ah, this was discussed before, let me loosely link these issues together". I also think it reads well for anyone that might look through the development, they can see which issues and PRs were referenced, and when :-)

Thanks for the discussion on this too, good luck with tinkering and if I figure something out in the future that STL has to do, I can reply here or if necessary reopen this issue.

[therob]

I just wanted to give a little update on this issue, as i found out some new details. I'm now pretty sure this is caused by GE-Proton8-3 (maybe in combination with Sniper, system libraries or graphics driver).

After Steam starts, it seems to process precached shaders with all installed Proton versions (but it looks like only the ones installed in compatibilitytools.d). When that happens, i noticed sometimes the same hanging Wine processes as it happened with MO2 including the one completely stuck winedevice.exe. But only with GE-Proton8-3. Other GE-Proton versions (7-38 and 7-55) never cause a problem. Additionally, the started d3ddriverquery64.exe seems to run much longer with GE-Proton8-3 than with the other versions.

To confirm my suspicion, i tried running MO2 with vanilla Proton 8 and SLR enabled. No problems so far with vanilla Proton 8. 🎉

[sonic2kk]

Oh that's quite interesting! Thank you for testing that, I didn't know that could've been a problem.

I will keep this in mind if others have similar issues, with MO2 or otherwise!