https://bugs.winehq.org/show_bug.cgi?id=51526
--- Comment #6 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Created attachment 70674 --> https://bugs.winehq.org/attachment.cgi?id=70674 Test hack
So the game creates a (hidden) window that's slightly larger than the screen, to offset the non-client area, but places it at (0,0) instead of something negative. In my case (1920x1080 screen), it creates a 1928x1107 window.
After it creates the window, it shows it. The problem is that the window manager gets involved at that point, and doesn't like such windows because they're off-screen. So it resizes it to 1920x1051 so it fits the work area (and for some reason, moves it to (0,2) as well, but that's probably not important), and then generates a ConfigureNotify event.
When wine's X11 driver sees this event, it attempts to sync the X11 window (that was resized/moved by the WM) with what the "windows side" sees it (which right now still believes the window to be in the old size). It does this by using a SetWindowPos if needed in X11DRV_ConfigureNotify (see winex11.drv/event.c), which among other things, ends up sending messages to the window.
For most apps this works fine, as they handle such alien SetWindowPos requests. There are exceptions though, and this game seems like one of them, but not the only one I know of. Note that theoretically, other apps could send SetWindowPos to any other app's window (at least if they have the required privilege), so it's not out of the ordinary what wine does here, it's just that the app doesn't expect it (but if you used e.g. AutoHotkey on Windows to send it at this specific time, it would probably crash as well).
Another bug that comes to mind is the old bug 15346, which suffers from similar issues due to that SetWindowPos and the WM moving/changing the window (in that case, WM refuses to move it off-screen), and seems unfixable without nasty hacks (the attached patch in it only band-aids the problem and breaks some older apps, as Alexandre mentioned on the mailing list, that expected the window to disappear if off-screen). In that bug, Winamp doesn't expect the SetWindowPos call either, it's not even processing a message loop at that point, and it keeps "track" of its movements manually, and that call breaks this assumption.
Strangely, for this particular game, it works fine if you put a Sleep for like 1000ms just before that call, which means it's something the game doesn't expect *at the time* it's generated, likely it uses something uninitialized yet. Sleeping for 100ms was not enough in my case though, but 1000ms is.
The attached hack (which obviously is *not* a solution) can be used to test if it works as well (you can try increase the Sleep if you want).
Other things that you can use that makes it work for me, and worth testing to replicate: Clear the "Allow the window manager to control the windows" in winecfg's Graphics tab. In this case the WM won't reconfigure the window if it doesn't like it. In Virtual Desktop it doesn't either, which is why it also works.
Ultimately I don't think this is fixable without some sort of nasty hack, unless someone comes up with a very clever idea, unfortunately. (and even then, getting Alexandre's approval for such fragile code will be very difficult)