https://bugs.winehq.org/show_bug.cgi?id=52593
--- Comment #1 from Zoë Sparks zoe@milky.flowers --- The following rough and hacky procedure doesn't prevent the crash, but it does delay it for a significant amount of time in my environment (maybe a couple minutes?). I found it on "accident" while trying to get more detailed logs around the crash.
1. From a fresh installation of MV, start it up with `WINEPREFIX=[PREFIX] wine 'C:\Program Files\KADOKAWA\RPGMV\RPGMV.exe'`. 2. Press "Continue" when you see the registration screen and wait. 3. Once you can use the program, create a new project. MV will crash a few seconds after the project is finished. The project itself will still be there; the crash occurs after project creation fully completes. 4. Make a FIFO (e.g. `mknod /tmp/wine_rpgmv_debug p`). 5. Edit the `projectFileUrl` registry key in `[Software\KADOKAWA\RPGMV]` and give it a blank string value. 6. Start the program with `WINEPREFIX=[PREFIX] WINEDEBUG=+seh,+relay wine 'C:\Program Files\KADOKAWA\RPGMV\RPGMV.exe' &>/tmp/wine_rpgmv_debug`. 7. Attach the read end of the FIFO to /dev/null (i.e. `cat /tmp/debug_log > /dev/null`). 8. Press "Continue" when you see the registration screen and wait for MV to start up. 9. Once it's up, open up the project open dialog to open your just-created project, but don't actually open it yet. 10. Stop sending the wine/MV output to /dev/null and instead redirect it to a file, ideally a file on a slow HDD with a lot of space as it will write several GB of text quickly. The point is just to slow the wine process down as much as possible. There are certainly more elegant ways of slowing Wine down than this if it's truly needed (patching Wine with some time-wasting junk code in the right place for example)—I'm mainly recording this process for the sake of having a record. 11. Actually open the project. 12. Once it's open, wait a bit, then stop sending the wine/MV output to your scratch file and instead send it back into /dev/null. 13. You should have a couple of minutes in which you can actually use MV almost-normally before the same type of crash occurs (the backtrace is identical etc.). It's pretty responsive with the output sent to /dev/null and everything seems to work properly during that time. The only thing that was a bit wonky is I found that if I tried to launch the project, nothing happened at first, but after the main editor crashed the game process would actually start up, perhaps just because of the extensive overhead introduced into the project start routines by all the logging. The game ran fine though after that point.
I wish I could say whether or not this is due to some periodic qt5webenginecore thread that's launched every so often by MV, such that the earlier crash shortly after opening a project is "dodged" by this procedure, or if it's the "same" crash that's merely delayed by the logging overhead.
I have yet to actually see the crash with +relay on, which is unfortunate. It may occur eventually, but if I'm actually redirecting the output to a file I run out of hard drive space before I see a crash. It's possible that the extreme slowness induced by +relay and output to a file on disk prevents the crash somehow, but also that it would still occur eventually if I waited long enough. The best logs I've gotten so far are with `WINEDEBUG=+seh,+tid,warn+all`, but although I can see the crash I have yet to make much heads or tails of them beyond that. You still end up with around 8G or so of log.
One idea I had was to try to cross-compile a debug build of the same version of Qt5 MV is using and drop in the relevant libraries from that, but (a) I'm not quite sure which Qt5 it's using yet and (b) cross-compiling Qt5 is its own wacky adventure, as I found out. Still, this strategy may yet yield fruit.