https://bugs.winehq.org/show_bug.cgi?id=27282
--- Comment #14 from Sebastian Lackner sebastian@fds-team.de --- Even if the patch probably works, I don't think its the right solution to solve the issue. This patch has the disadvantage that now theoretically WM_GETTEXT messages can cause race-conditions with other WM_{SET,GET}TEXT messages on the main thread where the window was created.
Thats not a big problem for the default message handler, but other applications which install their own handler will crash then. Based on the information available online its perfectly fine that GetWindowText(...) sends a WM_GETTEXT message, so I would guess that the conclusion from Fochts analysis is actually wrong. Just search for "GetWindowText deadlock" and you'll find lots of people on Windows having the same problem.
I would assume that either:
* Windows only uses this behaviour if the wndproc procedure is really the default one, where Windows know that its threadsafe. Not sure if that fixes the issue for both affected apps though.
* The Ole window shouldn't be created so early
* FindWindowExW shouldn't use WM_GETTEXT <-- Thats what I would guess. Best way would be to write some tests where WM_GETTEXT doesn't match the window title that is known to the wineserver.