http://bugs.winehq.org/show_bug.cgi?id=31442
--- Comment #34 from voidcastr voidcastr@gmail.com 2012-10-07 09:00:49 CDT --- Thanks for the clue, Henri!
+seh does not yield any output in the moment the freeze occurs or afterwards.
As far as I can tell from +tid, there are several threads doing the d3d/9 work, with split tasks: - "002f": deals with resource preparation (CreateTexture, surface operations, ...) - "0038" (/"0044", see below): deals with the actual rendering (swapchain ops, ...)
So, this is basically how GW2's multithreaded (actually: dualthreaded) rendering works... it's the first time we really get a notion of it, as far as I can tell.
Unsurprisingly, "002f" does all the initialization work and writes hundreds of thousands of lines to the log before "0038" is called for the first time.
Nevertheless there is a remarkable aspect about the second thread: It changes after some time, i.e. the ID of the tread announcing "new frames" in the log shifts from "0038" to "0044", with "0038" never being reused. Though, I don't think that means much -- possibly the game just lets the original rendering thread die and creates a new one (btw, the first thing both "0038" and "0044" ever log, respectively, is d3d9:d3d9_device_GetBackBuffer). I'd interpret this as being caused in the moment the launcher closes and the actual game gets started... at least this kind of makes sense.
When starting the application with its -dx9single flag, there is only one thread ("002f") doing all of the above work -- as expected.
Concerning +relay: I analyzed the log a bit and created an annotated except of it (see attachment). Thereby I concentrated on the last drawn frame and on the relay output of the threads with the aforementioned TIDs.
However, I did not yet take into account that the problem could also have its roots in a previous frame. This is because I hope that the reason for the freeze can already be derived from what I've got so far (in the attachment).
The most suspicious thing I see is a call to "user32.SendMessageW(...)" by TID 0044 apparently never returning... at least this could explain the many "KERNEL32.WaitForSingleObjectEx()" messages repeated over and over again by TID 002f, which might just be waiting for 0044. Btw, throughout the entire log (not just the excerpt), there is only one other call of TID 0044 to "user32.SendMessageW(...)" and that one's immediately returning (it can be seen at the end of the 3rd block in the attachment).
But I don't know if that's critical or how to go on from here. The reason for the freeze might also be something different in the log... or something I totally missed so far.
This is once more a request for help.