[ARM64EC/Labyrinth of Touhou]: Game crash in battles #4890
Description
What Game
Labyrinth of Touhou (Special Disc build). This is a Touhou fangame.
Official storefront: https://www.dlsite.com/home/work/=/product_id/RJ064430.html
I do have the English patches applied, but this crash also happens with an unpatched game.
Describe the bug
Entering a battle and attacking/using a spell results in the game hanging.
To Reproduce
Steps to reproduce the behavior:
- Enter game and go through all the dialogue. (
Zis effectively enter). - Go into the dungeon
- Walk around until an encounter.
- Do an attack or spell, game will hang.
Expected behavior
Battles do not crash using a traditional FEX 2508 rootfs. Have not been able test 2509.
I did try to build the arm64ec and wow64 FEX for wine using 2508 tag, but that did not fix the issue.
Screenshots and Video
The process to reproduce the error (I already have a minimal save file)
2025-09-15.17-28-01.mp4
System information:
- OS: Fedora 42
- CPU/SoC: Apple M2 under muvm (I did check this time)
- Video driver version: Mesa 25.2.0
- RootFS used: [eg: Ubuntu 21.10 Official Rootfs]
- FEX version: (FEXGetConfig --version) from source using 376d6ba
- Thunks Enabled: No
Additional context
- Is this an x86 or x86-64 game: x86
- Does this reproduce on AArch64 with Radeon/Intel/Nvidia: Untested
- Is this a Vulkan game: Using wine's Direct3D9 emulation, trace seems to show a lot of OpenGL32.
The exception causing a problem is
0024:trace:seh:dispatch_exception code=c0000005 (EXCEPTION_ACCESS_VIOLATION) flags=0 addr=0000000000000000
0024:trace:seh:dispatch_exception info[0]=0000000000000008
0024:trace:seh:dispatch_exception info[1]=0000000000000000
0024:trace:seh:dispatch_exception pc=0000000000000000 sp=00007ffffe1ff2e0 lr=0000000000000000 fp=0000000000000008
0024:trace:seh:dispatch_exception x0=0000000000000000 x1=0000000000000000 x2=0000000000000000 x3=0000000000000000
0024:trace:seh:dispatch_exception x4=0000000000000000 x5=0000000000000001 x6=0000000000000000 x7=0000000000000000
0024:trace:seh:dispatch_exception x8=00000000001126ec x9=00000000034f0020 x10=000000000011290c x11=0000000000000000
0024:trace:seh:dispatch_exception x12=0000000000003ffe x13=0000000000000000 x14=0000000000003ffe x15=0000000000000000
0024:trace:seh:dispatch_exception x16=000000000000403e x17=0000004fffa2b680 x18=000000007ffc0000 x19=00007ffffe1ff310
0024:trace:seh:dispatch_exception x20=0000000000000000 x21=000000000000000c x22=0000000000000000 x23=000000000000007f
0024:trace:seh:dispatch_exception x24=00007ffffe1ff860 x25=00007ffffe39e7e0 x26=00000000001126e8 x27=00000000ffeed967
0024:trace:seh:dispatch_exception x28=00007fffff843090 cpsr=20000000 fpcr=00000000 fpsr=00000010
0024:warn:seh:virtual_unwind exception data not found for pc 0000000000000000, lr 0000000000000000
Which is weird since pc is 0.
I have attached a +trace,+seh log. Wine popped out 6.3GB of data, but since I know the event happened after pressing Z to do an attack, I grabbed the area between the last GetKeyboardState event and the spam of exceptions before a stack overflow.
The exception only happens on W-thread 24. I think this is the game thread with all of the wine3d3 and PeekMessageA I see.
W-thread 138 is where all the D3D to OpenGL emulation happens. W-thread 130 doesn't appear to do anything interesting.
This may be a red-herring, but the only instance of NtFlushInstructionCache I see is very close to the crash.
I am unable to use winedbg inside of muvm due to the tty emulation seemingly being broken. See AsahiLinux/muvm#191
Interestingly I found a different error relating to an "invalid instruction" before I rebuilt FEX to a newer version. I haven't been able to find that error since.