http://bugs.winehq.org/show_bug.cgi?id=27406
--- Comment #1 from Piotr Pawlow pp@siedziba.pl 2011-06-06 17:52:04 CDT --- Created an attachment (id=35049) --> (http://bugs.winehq.org/attachment.cgi?id=35049) d3d+message+tid trace
This is how I understand what happens:
There are 2 threads involved: thread 0020 manages the window, and thread 0009 does the D3D stuff.
Thread 0009: - calls CreateDevice with hFocusWindow being the window from the other thread - wined3d hooks its wndproc to the window (not shown in the trace, as wined3d_register_window function has no TRACE call) - wined3d_device_create calls wined3d_device_acquire_focus_window with wined3d mutex held - wined3d_device_acquire_focus_window calls SetWindowPos - SetWindowPos sends WM_WINDOWPOSCHANGING message to the other thread
Thread 0020: - the message gets passed to wined3d_wndproc - wined3d_wndproc tries to acquire the mutex, which is held by the other thread, which in turn is waiting for the message to get processed == deadlock.
So, the solution seems to be either: - never call any API function that may send a message while holding the mutex or - somehow get rid of the mutex in the wined3d_wndproc