http://bugs.winehq.org/show_bug.cgi?id=33890
--- Comment #3 from Stefan Dösinger stefan@codeweavers.com 2013-08-21 06:32:26 CDT --- I'm not entirely sure what is going on here. The SetWindowPos call in wined3d_device_acquire_focus_window sends a WM_ACTIVATEAPP message, which prompts the app to call SetCooperativeLevel again. During the second call, ddraw attempts to recreate the swapchain. It thinks the application-provided window is a hidden d3d window it itself created because ddraw->dest_window is not set yet. The destruction of the Window causes the app to destroy the ddraw object. During the destruction, SetCooperativeLevel is called recursively another time to set DDSCL_NORMAL, which succeeds. Then, it proceeds with the second SetCooperativeLevel call, which eventually fails because ddraw->wine_d3d is NULL, so wined3d_get_adapter_display_mode segfaults.
I suspect that the WM_ACTIVATEAPP message that triggers the recursion is wrong, but have no proof for that yet. I have to compare with a Wine version before commit 6560135c to see if the ACTIVATEAPP message and recursive calls happen there or not. If they don't, I have to figure out why, because so far that's not obvious. If they happen, and I think they do, I have to find out if this is in line with Windows' behaviour, and if so, how the application got away with the recursive call prior to 6560135c.
A simple workaround for the crash is to set device->filter_messages to 1 for the SetWindowPos call in wined3d_device_acquire_focus_window. However, I don't know if this is correct.