https://bugs.winehq.org/show_bug.cgi?id=37609
--- Comment #2 from Drew Bugs bugs.drew@yahoo.com --- I think I have isolated the problem with FreeHand 9 demo hang.
With the resolution of bug 11582, the program spawns Process 3a (Thread 3b) from the initial process. Process 3a looks like it is a debug process that spawns Process 3c (Thread 3d) that is the Freehand.tty process. Thread 3d creates a number of windows successfully and then creates a listbox window 0x1025c.
003d:Call user32.CreateWindowExA(00000000,08911010 "Listbox",08911950 "Yo",00a00003,00000000,00000000,00000001,00000001,000101c2,00000000,08900000,00000000) ret=08906aff 003d:trace:win:WIN_CreateWindowEx "Yo" L"Listbox" ex=00000000 style=00a00003 0,0 1x1 parent=0x101c2 menu=(nil) inst=0x8900000 params=(nil) 003d:trace:win:dump_window_styles style: WS_BORDER WS_VSCROLL 00000003 003d:trace:win:dump_window_styles exstyle: 003d:trace:win:GetWindowRect hwnd 0x1025c (0,0)-(0,0)
It then tries to populate the listbox with a number of entries.. it goes through 20 cycles of sending LB_FINDSTRING and LB_GETTEXT messages followed by another 20 cycles of LB_GETTEXT messages.
Then the program issues a DestroyWindow call on a this newly created ListBox
003d:Call user32.DestroyWindow(0001025c) ret=08907171 003d:trace:win:DestroyWindow (0x1025c)
I think the program must do an analysis of the Window data and finds something it doesn't like and then calls DestroyWindow. The Windows created afterwards also get destroyed by the program. Finding out what the program doesn't like about 0x1025c is unfortunately beyond my limited debugging skills.
I have attached the relevant portion of the output log.