Does it work via the native version?
Obviously it shouldn't crash whether it's running via proton or native, but just out of interest.

Oh, I didn't even realize it has a native version. It crashes on native. Where can I report a bug with steam verified title?

Hmm I'm not sure.
If it's the native version then I'd be inclined to say the bug needs to be reported to the game devs.
Tho if the issue is isolated to the steam deck then i dunno if you should post in the steam discussion forums or on the steam for linux github.

@kisak-valve Might be able to provide some guidance.

It seems like its the "native" version, I thought it must be proton because there were some Windows informations and dlls in the crash report.
I already sent it to the dev and I will try to test it on another computer with linux.

I agree it does look a bit weird if it's running the native version when it posts this in the crash logs 🤔

SYSTEM INFO:

Platform: Win32NT (2)
OS version: Microsoft Windows NT 10.0.19043.0
OS version (uname): N/A
OS is 64-bit: True
Detected OS: Windows
.NET runtime version: 4.0.30319.42000
Running on Mono: True
Process is 64-bit: False

DirectX adapter #0
AMD RADV VANGOGH

DLL diagnostic:
  d3d11.dll: yes
  dxgi.dll: yes
  dwrite.dll: yes
  msvcr110.dll: yes
  vcruntime140.dll: yes

It looks like the steam deck is running it through proton.

I got a log file, so we can assume its running through proton?
steam-504210.log

FYI when I install it in Linux on my PC it runs the native version, which works without problems. When I run it through Proton 7, it crashes like on the Steam Deck

Ye it's running Proton then.
Unless the game has issues i would think the steam deck should default to native.

Tho it obviously shouldn't crash anyway so it would be nice to fix the issue if it influences other games.

Unless the game has issues i would think the steam deck should default to native.

It just reinstalled it on the Steam Deck and it definitely downloads the Windows Version (theres a Shenzhen.exe and no Shenzhen.bin.x86_64 like on my PC)

I also opened a bug report in the Steam Deck Forum

I just found out one can force to run the native version on the steam deck which works without crashing.

Developer of the Linux version here... this behavior on Deck was not what we asked for, but at the same time I don't have partner access for this title so I can't resubmit. If at all possible it'd be great to have this requeued on Valve's end.

The default depot should now be fixed.

Openbsd worked around it by suppressing the exception: https://github.com/rfht/fnaify/issues/34

btw, it looks List<Chip> in Solution is changed while the UI thread is busy looping through the same list to render the Chips to the screen. Disabling the Sort() (it unconditionally increases the version) with ShenzhenMod prevents the crash (but I'm not sure how important it is that the list is sorted correctly). I also didn't look to see which call-site is the cause. I suspect the ones that serialize the Solution state to StringBuilder are the culprit because they seem to be called when the chip is changed.

Update: I changed my patch to do the Sort() conditionally (only if the list is not already sorted) and it works great.

This is very interesting. Someone should probably test native .NET Framework to see if it has the same behavior when Sort() is called on an already-sorted list. Perhaps Mono's Sort() method is wrong.

Testing on Windows shows that List<T>.Sort() always increases the version, but List<T>.Sort(Comparison<T>) never increases the version. So it looks like a .NET Framework bug that SHENZHEN I/O inadvertently takes advantage of.

Pushed a change to match Framework's bug: https://github.com/madewokherd/wine-mono/commit/d7f93e4d9a29f9675172551f7fcd4d188b5f659d

Testing on Windows shows that List<T>.Sort() always increases the version, but List<T>.Sort(Comparison<T>) never increases the version. So it looks like a .NET Framework bug that SHENZHEN I/O inadvertently takes advantage of.

That's strange, because the code in dotnet's System.Collections.Generic.List increments the version in both code paths.

That'd be the current version of .NET (descended from .NET Core), not .NET Framework. My guess is they fixed the bug there but had to leave it in Framework for compatibility. And Mono shares that code, which is why it behaves correctly (as opposed to the broken way this application requires) in Mono.