http://bugs.winehq.org/show_bug.cgi?id=27406 --- Comment #1 from Piotr Pawlow <pp(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.