Looks like this is in the Wine platform backend, couldn't say for sure where it is though:

https://github.com/FNA-XNA/FAudio/blob/master/src/FAudio_platform_win32.c#L155

Hi, I'm the dev of Cosmoteer. Feel free to reach out to me if you need any info from me or there's anything I can do to help debug/solve this issue. (Though I have little experience with Linux or Proton.)

Unrelated, there's a separate issue/regression with text rendering in Cosmoteer being ugly/aliased in Proton 8+ (looks fine on Proton 7). Should I start a new issue for that or use this issue?

Okay, in that case, here's more info about the issue: Cosmoteer generates its font atlases dynamically on-the-fly using Windows text rendering APIs. (Cosmoteer is written in C#/.NET using WinForms, which I think uses GDI+ under the hood, though I could be mistaken.)

On Proton 7, here's what that looks like:

(Probably not quite as good as on Windows, but basically fine.)

But on Proton 8 or experimental, the text looks very ugly and aliased:

Both screenshots are from my Steam Deck where I am simply toggling the Proton versions.

@waltdestler Thank you! We are looking into this :)

@waltdestler Thank you! We are looking into this :)

Thank you! Please don't hesitate to reach out to me if I can help with either of these issues.

@gofman Are you able to provide any clues (a call stack maybe?) about where DestroyVoice is getting called? Cosmoteer caches voices and I believe should never call DestroyVoice until the player exits the whole game. To make sure, I put breakpoints everywhere I call DestroyVoice and they never get hit until the game exits.

@gofman Ah thanks, turns out the problem is specifically when a game simulation instances switches to another instance (which is what happens when changing the title screen planet), which I simply neglected to test. Thanks for the info, should be an easy fix on my end for the next patch. (I'm a little miffed that DestroyVoice simply fails silently in that case.)

Thanks for the other fixes too!

@gofman (I'm a little miffed that DestroyVoice simply fails silently in that case.)

Well, not on Proton (until yesterday's Exp [bleeding-edge]) where it crashes loudly :)

Great that it is clear now.

Maybe the problematic DestroyVoice is called implicitly from within a library used? When switching instances we get DestroyVoice call but surely no SetOutputVoices before that. Also a voice being deleted may be the output for submix voice, although it is maybe not the case here.

Aha, I found the problem! The .NET wrapper library I'm using (SharpDX, which is no longer maintained but until now pretty stable/bug-free) is bugged and will no-op if SetOutputVoices is called with no output voices. Easy work-around on my end. Thanks for alerting me to this issue and helping to debug!

I'll fix this for the next public Cosmoteer patch, but let me know if you'd like me to upload the fix to a beta branch if you want to test on your end.

Sure I can check the pre-release game. Also if you can run Cosmoteer on Proton and enable default logging with PROTON_LOG=1 %command% in launch parameters, default log from Proton Experimental [bleeding-edge] will have 'err:' lines (grep err: ~/steam-799600.log) if the active voice destroy was attempted.

Okay I have a build with the fix up on the test branch which can be unlocked using the ultra-secure password testtesttest.

(Also just confirming that the text aliasing issue appears to be fixed on my Steam Deck on Experimental bleeding-edge. Thanks for that too!)

Yes did a quick try and now deleting voices when switching instances seems to go normally. It goes normally on game exit even (when previously was also showing that).

One thing to note, now it seems to set SetOutputVoices with NULL pSends. At least in our implementation (which I didn't check for this aspect but more likely it is the same on Windows) it is not exactly the same as setting with non-NULL pSends and 0 voice count. The latter removes any voices from output, the former (NULL pSends) stes the voice output to mastering voice. Which is likely fine, but I don't know all the details about the voices life in the game.

Yeah that's my current workaround for the SharpDX bug. I think it should be fine because the voices get stopped before SetOutputVoices is called.

Hi again!

Another issue that some players are reporting is that occasionally some keys (such as using WASD to pan the view around) get virtually "stuck" in the pressed state until they are physically pressed and released again. It's been reported by players with physical keyboards, and I've also personally had it happen on my Steam Deck with the thumbstick configured to emulate WASD.

It's just common enough to be annoying, but rare enough to be really hard for me to debug or figure out any kind of repro. I'm not sure how to investigate further due to my inability to consistently repro the problem. But I'm pretty confident it's a Proton issue and not a game issue because it doesn't happen on Windows.

FWIW, Cosmoteer uses the Windows raw input API to get keyboard and mouse input.

Here's another font rendering issue, this time with Chinese characters, some of which appear corrupted/garbled while most are fine. Here's a screenshot of what Cosmoteer looks like on Steam Deck with the language set to Chinese:

And here's what it looks like on Windows:

unable to send report with F11
reproduction:

1. open game
2. play
3. press F11
4. write something
5. press

log: steam-799600.tar.gz
at line 3852367 there this

17000.888:011c:0224:err:ole:ifproxy_release_public_refs IRemUnknown_RemRelease failed with error 0x800706be
17000.888:011c:0224:warn:seh:dispatch_exception backtrace: --- Exception 0x800706ba.
17000.888:011c:0224:trace:seh:dispatch_exception code=800706ba (unknown) flags=0 addr=00006FFFFFC0D107
17000.888:011c:0224:trace:seh:dispatch_exception rip=00006fffffc0d107 rsp=0000000004cbe5b0 rbp=0000000004cbe6a0 eflags=00000202
17000.888:011c:0224:trace:seh:dispatch_exception rax=0000000004cbe5d0 rbx=0000000004cbf460 rcx=0000000004cbe5d0 rdx=0000000000000000
17000.888:011c:0224:trace:seh:dispatch_exception rsi=0000000003bf1178 rdi=0000000004cbe768  r8=0000000000000000  r9=0000000000000000
17000.888:011c:0224:trace:seh:dispatch_exception r10=0000000000000000 r11=0000000000151800 r12=0000000004cbf460 r13=0000000000000003
17000.888:011c:0224:trace:seh:dispatch_exception r14=00006ffffef1feec r15=0000000000000000 mxcsr=00001fa0
17000.888:011c:0224:trace:seh:call_vectored_handlers calling handler at 00006FFFFD810600 code=800706ba flags=0
17000.888:011c:0224:trace:seh:call_vectored_handlers handler at 00006FFFFD810600 returned 0
17000.888:011c:0224:warn:seh:virtual_unwind backtrace: 00006FFFFFC0D107: L"kernelbase.dll" + 000000000000D107.

@GyomeiHimejima9906 it should be fixed in proton experimental bleeding ege

unable to use same mod on the workshop due the a not found dll file (C:\windows\Microsoft.NET\Framework64\v4.0.30319\wminet_utils.dll)

steam-799600.log
games's log (NOT proton log).txt

Cosmoteer recently upgraded to .NET 10 and many players are now reporting random freezes/crashes during gameplay on Proton. Some claim some subset of 10/11/hotfix/experimental either works or doesn't work, but there's no consistency.

log2.txt is a Proton log file sent to me by one such player. Possibly relevant are these two lines:

1198383.905:0128:03ac:fixme:unwind:call_user_apc_dispatcher flags 0x3 are not supported.
1198383.907:0128:012c:fixme:unwind:call_user_apc_dispatcher flags 0x3 are not supported.

Please let me know if there's any additional information I can collect or anything I can do to help debug.

Cosmoteer recently upgraded to .NET 10 and many players are now reporting random freezes/crashes during gameplay on Proton. Some claim some subset of 10/11/hotfix/experimental either works or doesn't work, but there's no consistency.

log2.txt is a Proton log file sent to me by one such player. Possibly relevant are these two lines:

1198383.905:0128:03ac:fixme:unwind:call_user_apc_dispatcher flags 0x3 are not supported.
1198383.907:0128:012c:fixme:unwind:call_user_apc_dispatcher flags 0x3 are not supported.

Please let me know if there's any additional information I can collect or anything I can do to help debug.

Could you please attach full, uncut compressed log? Extracting parts with interpretation doesn't help (in this particular case, the fixme will be present in any up to date .Net Core app but that is not necessarily responsible for the actual problem).

Also, exact steps for the quickest reproduction might be helpful.

@gofman Sorry about that, the player who sent me that log only sent me the final 100 lines. Here's an unabridged compressed log. Unfortunately I'm not aware of specific repro steps other than play Cosmoteer and select Career mode; it sounds like it's pretty random but usually crashes within 5-10 minutes. I suspect a race condition of some sort but am of course not sure.

steam-799600-proton-11-beta-original-configuration.zip

Thanks! It so far looks like those errors are more likely just the consequences of prior error with .Net just trying to shutdown threads this way (probably successfully). Is it possible to get a log with PROTON_LOG=+module,+path,+file ? That may be big but should compress very well.

Sure, I'll ask players to get that log.

I should add that Cosmoteer has a built-in freeze detection watchdog that gets triggered if the main thread is frozen for 10+ seconds. This watchdog attempts to log the call stack of every Cosmoteer thread, which it does by spinning up another process which inspects call stacks of the main process. I believe the watchdog's call stack logging is broken on Proton so there may be errors related to that in the Proton log, but a 10+ second freeze on the main thread is NOT normal; I believe there's a different underlying issue that's causing the main thread to freeze, and the watchdog issue is secondary to that.

There is no any process started though after Cosmoteer.exe in the log (that would be seen).

@waltdestler I tried to repro, let it sit after starting a new game for some 10 min, no luck. But I figured that C++ exceptions which I suspected could be related happen without any hang normally.

Then, how common is the problem, is that specific user or seems broken for many people? Only now payed attention, this quite possibly might be an issue in user's setup:

WARNING: Low /proc/sys/vm/max_map_count: 65530 will prevent some games from working

@waltdestler I tried to repro, let it sit after starting a new game for some 10 min, no luck. But I figured that C++ exceptions which I suspected could be related happen without any hang normally.

Then, how common is the problem, is that specific user or seems broken for many people? Only now payed attention, this quite possibly might be an issue in user's setup:

WARNING: Low /proc/sys/vm/max_map_count: 65530 will prevent some games from working

@gofman It seems broken for many people, though fwiw it does seem to be fine or at least much better on Steam Deck; all but one of the reports I have are on distros other than SteamOS, AFAIK (and I'm not 100% sure that one report is related).

Here are the requested log files from the same user as above:
log part 1 xaa.zip
log part 2 xab.zip

@waltdestler No slightest queue unfortunately from this log.

WARNING: Low /proc/sys/vm/max_map_count: 65530 will prevent some games from working

I think this one should be sorted out first in setup, might be responsible for problems. It can be increased (and many distros now use much higher limit by default, on SteamOS that is 2147483642 (i. e., virtually unlimited, increasing this limit will not result in actual increase of any resource usage if an app is not trying to use more memory maps than the limit (and if it is hitting the limit it is going to be broken. Maybe also worth trying to reboot the machine (it wasn't for some two weeks, who knows what errors have stacked up, just e. g., what if there was a GPU crash once somewhere, not necessarily in this game which wasn't fullyt recovered).

If that is reproducible for many users it could potentially help if they could be posting the info here:

• repro conditions, quite maybe it is not the same issue for all the users and many have very specific problem in specific place / actions;
• system information;
• default Proton log;
• Output of dmesg command.

Quite possible other people have a different issue which will show up in log or there is some setup / distro pattern which can be used to reproduce and narrow down the issue.

Replying to https://github.com/ValveSoftware/Proton/issues/7514#issuecomment-4421895005

Thanks! I'll ask the players to try the max_map_count and get the other information.

In the meantime, a couple more clues:

• Several players have reported that disabling Cosmoteer's multithreading (which can be done with --cores 1) solves the freezes.
• A couple players have reported that using GE-Proton10-34 also resolves the freezes. (Without needing to disable Cosmoteer's multithreading.)
  Right now, I'm suspecting a deadlock in Cosmoteer's multithreaded job scheduler that's caused by some incompatibility between .NET 10 and Proton. (But possibly fixed in GE-Proton10-34.)

And here's another log file from a different player.

steam-799600.zip