http://bugs.winehq.org/show_bug.cgi?id=44827 --- Comment #26 from Armonius <manicat(a)outlook.com> --- Okay after much digging and understanding (Got to thank you again Sir Bernhard for your notes on a debugging attempt) This is a recursive deadlock that occurs between 32bit and 64bit applications. I could be wrong here, but it seems like WoW64 implementation doesn't make it easy for sharing thread objects and handles across different bit architectures in FL Studio... It's the SetParent() function that doesn't return when ilbridge is trying to create a window. I'm still trying to figure out why specifically, but it's highly likely that FL is using some COM/RPC call that works in windows that's not implemented in WINE. The chain of events is like this 1.FL spawns ilbridge.exe 2.ilbridge loads the plugin 3.The plugin creates a window 4.ilbridge tries to SetParent(pluginWindow, FLStudioWindow) 5. FL64 waits for the plugin bridge window Neither side proceeds because SetParent never returns under Wine.. it could be the WOW64 or WIN32U architecture There's many ways to attempt to solve the problem.. The hard and robust approach would be to try to improve WINE multibitness HWND parenting, but that takes me having a much stronger understanding of Windows internals and WINE to not just create a bunch of patches that have a lot of regressions. It would be easier to try to build a SetParent() shim that bypasses the cross-bitness pathway to the plugin and uses some x11 reparent call to manage it, or try to replace any blocking SendMessage/COM marshal that would wait for the host UI thread with PostMessage/asynchronous dispatch or marshal the call into an RPC thread pool so the caller won’t block. I'm still considering what to try.. -- 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.