[Bug 44827] New: FL Studio: 32-bit/ 64-bit VST plugin bit bridging soft locks the host
https://bugs.winehq.org/show_bug.cgi?id=44827 Bug ID: 44827 Summary: FL Studio: 32-bit/64-bit VST plugin bit bridging soft locks the host Product: Wine Version: 3.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ajduck(a)outlook.com Distribution: --- Trying to bridge a 32-bit VST plugin in FL Studio 64-bit, or bridge a 64-bit VST plugin in FL Studio 32-bit, leads to this being outputted: 003c:err:ntdll:RtlpWaitForCriticalSection section 0x1ac6028 "?" wait timed out in thread 003c, blocked by 002a, retrying (60 sec) And the DAW soft locks with a loading cursor as it blocks the UI until the plugin's loaded, forever trying to bridge the plugin. (By "soft lock", I mean that FL Studio itself is still responsive, but you're completely blocked from doing anything and the only way to get out of it is to kill the process.) ====== Steps to reproduce: 1. Download and install FL Studio 12 Demo: https://support.image-line.com/redirect/FLStudio_Installer_Google The demo and the full version are the same executable. You will need the Arial font or any ttf named as arial.ttf in "C:/Windows/fonts/". If you have Winetricks just run "winetricks corefonts" (you will need the cabextract package). 2. Download any 32-bit or 64-bit VST to test. This is the one I tried, a 32-bit plugin (http://veg.by/en/projects/syxg50/). The plugin itself is working perfectly. You can use any VST you want, as long as you know whether it's 32-bit or 64-bit. Put the dll file in "~/.wineprefix/drive_c/Program Files (x86)/Steinberg/VstPlugins/". 3. Open the FL Studio version which DOESN'T match the instruction set of the VST you're using. If you're using a 32-bit VST plugin, open FL Studio 12 (64-bit). If you're using a 64-bit VST plugin, open FL Studio 12 (32-bit). (If you're using the VST I linked to, open FL Studio 12 (64-bit)) 4. When FL Studio is launched for the first time, a featured project file is automatically loaded. Click "File" in the top left corner and then "New" to create an empty project. 5. Click "Options" > "Manage Plugins" 6. Click the "Start scan" button with "Verify plugins" enabled (make sure the light is red). Let it scan for plugins. 7. Close the window, click "Add", and then "More plugins..." (under System) 8. Find and select "S-YXG50" (or if you used another VST, pick that). 9. Because the instruction set of the VST plugin doesn't match the host program's (FL Studio), FL Studio will try to run the VST plugin under a "bridge" (which uses ilbridge.exe, the bridging program installed as part of FL Studio). However, the plugin never loads. The UI blocks any interaction while plugins are being loaded so FL Studio is effectively soft locked. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 ajduck(a)outlook.com changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 ajduck(a)outlook.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|FL Studio: 32-bit/64-bit |FL Studio: Soft locks |VST plugin bit bridging |forever when attempting to |soft locks the host |"bit bridge" a | |32-bit/64-bit VST plugin -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 ajduck(a)outlook.com changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=45269 --- Comment #1 from ajduck(a)outlook.com --- Still happens as of Wine 3.9 and FL Studio 20. The recently released FL Studio 20 actually soft locks at launch with the same error (RtlpWaitForCriticalSection) now, see bug #45269. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 --- Comment #2 from ajduck(a)outlook.com --- Still happening as of Wine 3.19 and a distro upgrade (a clean install) from elementary OS 0.4 Loki (based on Ubuntu 16.04) to elementary OS 5.0 Juno (based on Ubuntu 18.04). Weirdly after doing this clean install, the soft lock when launching FL 20 that I described in the previous comment isn't happening anymore. (Might be to do with the new 18.04 base?) ---------- Link to more recent version of FL: http://demodownload.image-line.com/flstudio/flstudio_win_20.0.5.681.exe $ sha1sum flstudio_win_20.0.5.681.exe 11901b66a65c526203dacbab7ec6a3c61edb1553 flstudio_win_20.0.5.681.exe -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 --- Comment #3 from ajduck(a)outlook.com --- Still happens as of Wine 4.4 Staging. -------- Some additional info: There are two ilbridge.exe executables, one for 32-bit and one for 64-bit. Here's an example of what processes (+ options) are running when bit-bridging is attempted: For FL Studio 32-bit: C:\Program Files (x86)\Image-Line\FL Studio 20\FL.exe C:\Program Files (x86)\Image-Line\FL Studio 20\System\Tools\Bridge\64bit\ilbridge.exe -wrapper -address {73DA306F-6855-4F59-B63E-ADF54D47013B}1 -processid 52 -dpiaware For FL Studio 64-bit: C:\Program Files (x86)\Image-Line\FL Studio 20\FL64.exe C:\Program Files (x86)\Image-Line\FL Studio 20\System\Tools\Bridge\32bit\ilbridge.exe -wrapper -address {888E87B6-9C3E-4851-9CE8-C3252E9D11A3}1 -processid 54 -dpiaware As you can probably see, the 32-bit version of FL uses the ilbridge.exe executable in the 64bit folder (to bridge a 64-bit plugin), and vice-versa for 64-bit FL. An address and process id is passed as options into the bridging executable. As mentioned in the OP, it waits for something and keeps eventually timing out: 0048:err:ntdll:RtlpWaitForCriticalSection section 0x17e8b20 "?" wait timed out in thread 0048, blocked by 0035, retrying (60 sec) -------- I ran FL64.exe with WINEDEBUG='+relay,+tid' and got it down to a 15MB log: https://aljelly.keybase.pub/linux%20related/fl64-bridging-32bit-wine-filtere... (I strongly recommend right-clicking the link, select "Save Link As..." and then looking at the file through less.) To cut the log down in size I cut everything out before the first occurrence of CrossOver.dll (the 32-bit VST I'm trying to bridge), and filtered out any lines with 'gdi32', 'user32', 'winex11', or 'window proc' in them (because I *think* most of those are just GUI related). A lot of the file might be irrelevant to the issue however (the lines to do with fonts are very likely so). Some of it might be due to unrelated .NET Framework services running in the background. Line 743 has the wait timed out error message. Probably strings of relevance to search for are: "CrossOver" or "CrossOver.dll", "0037" and "004a" (thread ids related to the bridging attempt), "Wrapper" or "Wrapper says", "ilbridge.exe", and "{E682D1D3-5CF7-4213-B873-D426EF623DCB}". -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 --- Comment #4 from ajduck(a)outlook.com --- I've discovered something about this behaviour that could further pinpoint what the underlying issue is: It only happens *when you try to load the GUI* of a bit-bridged plugin. If you load 32-bit only plugins (as in plugins with no 64-bit equivalent) to a project file in 32-bit FL Studio, close all the plugin GUIs and save the project, and then load the same project file in 64-bit FL Studio, FL does not hang when it's finished loading the project. The plugins work totally fine sound-wise, no hanging from that either. It only hangs with the RtlpWaitForCriticalSection timing out when you try to open the GUI of one of those plugins. Vice versa for 64-bit plugins in 32-bit FL Studio. I don't think it's to do with the rendering of the GUI itself, rather I expect it's something more to do with the process of loading the GUI, but this is a guess. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 --- Comment #5 from ajduck(a)outlook.com --- Also if anyone is looking for a workaround to this issue, you can use jBridge (though the author does not give it out gratis). It only works with VST1 and VST2 though. You have to use it in separated GUI mode however because the integrated GUI mode causes the plugin GUI to be glitchy and it will usually hang FL when you try to close the GUI (probably some separate Wine issue, don't have a Windows installation to test on). The hang can be fixed with a config change but the glitching can't. jBridge creates a .dll and config file for each plugin you want to use jBridge with, and there seems to be no global settings or override or anything (and the default config text file doesn't seem to work correctly), so you have to set this per plugin. Here's a short fish script to set all the jBridge plugin configs to separated GUI mode (and some other settings that make the mode easier to use) after you create them with the jBridge tool: #!/usr/bin/env fish for cfg in "$HOME/Documents/jBridge/SettingsFilesFor32BitPlugins/"*".jBridge" string replace "USE_SEPARATED_GUI 0" "USE_SEPARATED_GUI 1" < "$cfg" > "$cfg" # The below are optional and may already be on by default but I recommend them string replace "GUI_WINDOW_ALWAYS_ON_TOP 0" "GUI_WINDOW_ALWAYS_ON_TOP 1" < "$cfg" > "$cfg" string replace "GUI_AUTOCLOSE 0" "GUI_AUTOCLOSE 1" < "$cfg" > "$cfg" end for cfg in "$HOME/Documents/jBridge/SettingsFilesFor64BitPlugins/"*".jBridge" string replace "USE_SEPARATED_GUI 0" "USE_SEPARATED_GUI 1" < "$cfg" > "$cfg" # Ditto string replace "GUI_WINDOW_ALWAYS_ON_TOP 0" "GUI_WINDOW_ALWAYS_ON_TOP 1" < "$cfg" > "$cfg" string replace "GUI_AUTOCLOSE 0" "GUI_AUTOCLOSE 1" < "$cfg" > "$cfg" end You have to scan for plugins again in FL once you've created the jBridge dlls. Even though the jBridged plugin .dll will show up separately in the plugin database with [jBridge] prepended to the name, it will load in place of the 32-bit version if you try to load it in FL64 (and vice versa). -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 ajduck(a)outlook.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|FL Studio: Soft locks |FL Studio: Soft locks |forever when attempting to |forever when attempting to |"bit bridge" a |load the GUI of a |32-bit/64-bit VST plugin |"bit-bridged" 32-bit/64-bit | |VST plugin -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 --- Comment #6 from ajduck(a)outlook.com --- I've discovered an even better workaround that doesn't even require jBridge! It's so much better! (This workaround supersedes the workaround in the previous comment.) FL Studio has the option to show an external window for the GUI for a bridged plugin. It turns out that FL shows the GUI of a bit-bridged plugin absolutely fine when it's shown in an external window (I think the external window might be from the ilbridge.exe process itself). The hanging problem seems to be specifically when FL tries to show a bit-bridged plugin's GUI in the internal FL Studio window representing the plugin. To workaround this without any external programs, all you need to do is this: 1. Open FL, go to Options > Manage plugins and find the plugins you're coming across this Wine bug with. Find out whether they're 32-bit or 64-bit only. 2. Open the FL version with the same bit size as the plugin you want to get working in the other bit version. Open FL 32-bit for 32-bit plugins and FL 64-bit for 64-bit plugins. 3. For each plugin you want to workaround the Wine bug with, open the plugin and go to the VST wrapper settings*. Then click on the "Processing" tab at the top and enable "External window" under the top-most section ("Compatibility options"). * Click on the cog icon in the plugin window's headerbar if it's not green and then click on the plug & cog icon in the bar below the headerbar Now when you show the GUI of that plugin in the other bit version of FL, it won't hang. -------- By the way, in the case you accidentally cause FL to lock up from this specific Wine bug and you really want to release FL from it (e.g. you really want to save the project file), you _can_ actually release FL from it. You need to end the ilbridge.exe process that FL is waiting for. You can either use Wine's taskmgr or a native process manager: - Native process manager: Go to a native process manager that shows PIDs and end the ilbridge.exe process that has the highest PID. - Wine taskmgr: End the ilbridge.exe process that shows 0:00:00 CPU time. FL will be responsive again. You won't be able to reload the plugin without triggering the hanging again though (because the only way to load the GUI of the plugin is to click the button in the plugin window). The project file will save fine though and you won't lose the plugin or it's settings. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 ajduck(a)outlook.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|FL Studio: Soft locks |FL Studio: Soft locks when |forever when attempting to |attempting to show the GUI |load the GUI of a |of a "bit-bridged" |"bit-bridged" 32-bit/64-bit |32-bit/64-bit VST plugin in |VST plugin |an internal window -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 --- Comment #7 from ajduck(a)outlook.com --- If you use fish shell here's a quick way to enable external GUI for all plugins when they're bridged: 1. Close all Wine-using programs 2. Open the terminal 2. Change directory to the wineprefix you run FL under, e.g. `cd ~/.wine` 3. Run `cp user.reg user.reg.BK` (backing up user.reg just in case) 4. Run `string replace '"BridgedExternalWindow"=dword:00000000' '"BridgedExternalWindow"=dword:00000001' < user.reg > user.reg` -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 --- Comment #8 from ajduck(a)outlook.com --- This is still present as of Wine 4.20. Also, two corrections to my previous comments: - You need to open a VST plugin before a registry entry is created, so you'll have to open them using the native bit version first or load the VST without showing the GUI in a non-native version (e.g. Patcher might work). If you've already opened VST plugins in the past then the fish shell instructions will be useful as the registry entries will already be there. But if you're opening each plugin natively (i.e. not bridging) then you might as well enable external window the usual way. - It turns out that you may actually lose your plugin settings if you kill one of the ilbridge.exe processes (to revive a frozen FL) and then save. Your possible options to prevent losing your settings: making sure all plugins have external window enabled beforehand so you don't encounter bridging-related lockups, using "save new version" to get the settings later from previous versions, and enabling automatic backups (to fetch the previous settings from a backup). -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 Andrzej Kilijański <and3md(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |and3md(a)gmail.com --- Comment #9 from Andrzej Kilijański <and3md(a)gmail.com> --- This is still present as of Wine 5.00. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 --- Comment #10 from Andrzej Kilijański <and3md(a)gmail.com> --- This is still present as of Wine 5.00. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 --- Comment #11 from Andrzej Kilijański <and3md(a)gmail.com> --- Created attachment 66344 --> https://bugs.winehq.org/attachment.cgi?id=66344 console log -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 lyghters <lyghters(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lyghters(a)gmail.com --- Comment #12 from lyghters <lyghters(a)gmail.com> --- Still present in Wine 5.2 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 Jan R <jan.riewe(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jan.riewe(a)gmx.net --- Comment #13 from Jan R <jan.riewe(a)gmx.net> --- Still present in 5.9 additional to the solution from ajduck(a)outlook.com and alternative to replace the String using vim would be: 1. Close all Wine-using programs 2. Open the terminal 2. Change directory to the wineprefix you run FL under, e.g. `cd ~/.wine` 3. Run `cp user.reg user.reg.BK` (backing up user.reg just in case) 4. Run `vim user.reg` 5. :%s/BridgedExternalWindow"=dword:00000000/BridgedExternalWindow"=dword:00000001/g 6 :wq In my case this workaround did not work. Linux work 5.6.15-1-MANJARO #1 SMP PREEMPT Wed May 27 20:38:56 UTC 2020 x86_64 GNU/Linux -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 Mikhail <mikhail.v.gavrilov(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mikhail.v.gavrilov(a)gmail.co | |m -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 --- Comment #14 from Mikhail <mikhail.v.gavrilov(a)gmail.com> --- The param BridgedExternalWindow is absent in Wine 5.13 registry. [mikhail(a)localhost .wine]$ grep BridgedExternalWindow user.reg [mikhail(a)localhost .wine]$ -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://web.archive.org/web | |/20180930122250/http://demo | |download.image-line.com/fls | |tudio/flstudio_win_20.0.5.6 | |74.exe CC| |focht(a)gmx.net Status|UNCONFIRMED |NEEDINFO Summary|FL Studio: Soft locks when |FL Studio 12.x - 20.x: Soft |attempting to show the GUI |locks when attempting to |of a "bit-bridged" |show the GUI of a |32-bit/64-bit VST plugin in |"bit-bridged" 32-bit/64-bit |an internal window |VST plugin in an internal | |window Ever confirmed|0 |1 --- Comment #15 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, adding stable download link via Internet Archive. https://web.archive.org/web/20180930122250/http://demodownload.image-line.co... $ sha1sum flstudio_win_20.0.5.674.exe 521e8558d3cbc54d5f42add5658efe44eaec4a5f flstudio_win_20.0.5.674.exe $ du -sh flstudio_win_20.0.5.674.exe 673M flstudio_win_20.0.5.674.exe Regards -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 brokenaria <behindthewallofnoise(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |behindthewallofnoise(a)gmail. | |com --- Comment #16 from brokenaria <behindthewallofnoise(a)gmail.com> --- hello! figured i would duck in and give an updated method on how to fix your 32-bit VSTs without any externals now that FL Studio no longer comes with a 32-bit version as of 20.9. if you take the Fruity Wrapper plugin by itself and load an empty wrapper into a plugin slot, click the settings cog, tab over to the VST wrapper settings, and then load whatever 32-bit VST it is that you're trying to use into the exact same slot as that Fruity Wrapper, it loads without ever showing the GUI and goes straight to the settings, so you can tab over to processing and set it to be an "external window" like usual. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 wigglywoogly <wigglywoogly(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wigglywoogly(a)gmail.com --- Comment #17 from wigglywoogly <wigglywoogly(a)gmail.com> --- I could not get the registry workarounds proposed by ajduck(a)outlook.com or Jan Rto work. However, massive thanks to brokenaria for that clever workaround!!! I finally did get a 32-bit VST to run without crashing with this method!!! This is on * Ubuntu 22.04 * Wine 9.0 * FL Studio 21.2.2 I also found that loading a project that already contained 32-bit VSTs worked OK and played the audio properly, until you actually tried to use these VSTs' GUIs, which caused the crash. Thanks again. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 --- Comment #18 from wigglywoogly <wigglywoogly(a)gmail.com> --- So the solutions proposed by ajduck(a)outlook.com and Jan R didn't quite work for me, but they were a good starting point. I believe the reason they didn't work is that many of the 32-bit VSTs I was trying to modify only had a very minimal registry entry, and didn't contain the keyword "BridgedExternalWindow", and so attempting to modify these with a find+replace approach had no effect. Instead by manually modifying the registry in wine regedit, I navigated to the entries for the relevant VSTs: HK_USERS > S-1-5-21-0-0-0-1000 > Software > Image-Line > Shared > Plugins > Fruity Wrapper > Plugins and found my VSTs listed by plugin author. For each of the misbehaving ones, I created a new Hexidecimal DWORD called "BridgedExternalWindow" and gave it the value 1. Then on attempting to run these VSTs in FL Studio, they open in External Window mode by default, and no more crashes. Happy days! Many thanks to the other users who investigated this issue, and I hope this solution helps somebody else. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 Kylie McClain <kylie(a)somas.is> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kylie(a)somas.is -- 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.
https://bugs.winehq.org/show_bug.cgi?id=44827 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|1 |0 Status|NEEDINFO |UNCONFIRMED -- 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.
http://bugs.winehq.org/show_bug.cgi?id=44827 Armonius <manicat(a)outlook.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |manicat(a)outlook.com --- Comment #19 from Armonius <manicat(a)outlook.com> --- I have to thank ajduck(a)outlook.com and @wigglywoogly for the workarounds.. I spent weeks dealing with this issue and not even being aware of these workarounds. I have no knowledge of debugging and reverse engineering but for the past weeks I've been familiarizing myself with cpu registers and memory management to solve this issue. Here's what I've learned: you all were right on it being a loading hang. I used x64dbg and IDA pro to inspect the call stack on 2 different version of wine. I mainly focused on Soda 9(in bottles) but I started with wine 10.16 staging . In both Wine versions, the last api call before the crash was ntdll.WaitforMultipleObjects(). I traced down what was calling it to Fruity_Wrapper_x64.dll . I think it's a memory corruption issue due to some mismatch in architecture (64bit to 32bit) or 32bit to 64bit in old versions. The wait for multiple objects function is fundamentally a synchronization call to another thread(i think ilbridge), but the handle that the ntdll function is being passed is invalid. I can give more information but I'm going to see if I can patch it and see if it works (For the guys who know more than me about this, The bug is a memory corruption caused by an 8byte (QWORD) Handle being partially overwritten by a 4byte (DWORD) reference count due to incorrect structure offset usage in the 64bit host) -- 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.
http://bugs.winehq.org/show_bug.cgi?id=44827 --- Comment #20 from Armonius <manicat(a)outlook.com> --- Wow well I was way in over my head with this one...I traced the function that was waiting inside of fruity_wrapper_x64.dll, I think I found the one that initializes the reference count that's very suspicious, but tracing specifically what created the handle led to me being totally lost... it's inside of a vtable with many functions that gave me no leads... apparently I didn't understand enough about the compiler FL uses to actually get a better dissassembly from, IDA.. I also need a couple of tools to make it much easier because I'm a total noob at this. I'm having to use some static analysis and a a debugger to trace it down, but yesterday I couldn't actually find what creates the handle. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=44827 Bernhard Übelacker <bernhardu(a)mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu(a)mailbox.org --- Comment #21 from Bernhard Übelacker <bernhardu(a)mailbox.org> --- Created attachment 79563 --> http://bugs.winehq.org/attachment.cgi?id=79563 notes of a debugging attempt Looks like FL64.exe and ilbridge.exe synchronize their communication via events "{...}1_0_reader_evt_signal" and "{...}1_2_writer_evt_reader". Because of that many threads and events, and at some places it waits for multiple events, I cannot point to something specific missing. Because of the "TMethodImplementationIntercept" showing up in backtraces, FL64.exe and its Dlls seem to be written in Delphi. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=44827 --- Comment #22 from Armonius <manicat(a)outlook.com> --- @Bernhard(In reply to Bernhard Übelacker from comment #21)
Created attachment 79563 [details] notes of a debugging attempt
Looks like FL64.exe and ilbridge.exe synchronize their communication via events "{...}1_0_reader_evt_signal" and "{...}1_2_writer_evt_reader".
Because of that many threads and events, and at some places it waits for multiple events, I cannot point to something specific missing.
Because of the "TMethodImplementationIntercept" showing up in backtraces, FL64.exe and its Dlls seem to be written in Delphi.
DELPHI!!!! that explains it... i couldnt understand these VMT tables.. I spent 4 days just reading them up... maybe i can use the delphi helper plugin to parse these in IDA... I think the FL64.exe doesnt use delphi though... whoa I got to say i dont get backtraces as clean as you do... you used lldb? how do you configure that with wine? Thank you for your effort sir. I have much to learn from your notes.... I want to see if i can check each handle and see where each is coming from the moment it is freezing, but i can barely debug it in IDA via WINE. I need ScyllaHide to hook the anti-debugging functions but the version of ScyllaHide that has been released doesnt support my version of IDA. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=44827 --- Comment #23 from Armonius <manicat(a)outlook.com> --- Sir Bernard U(In reply to Bernhard Übelacker from comment #21)
Created attachment 79563 [details] notes of a debugging attempt
Looks like FL64.exe and ilbridge.exe synchronize their communication via events "{...}1_0_reader_evt_signal" and "{...}1_2_writer_evt_reader".
Because of that many threads and events, and at some places it waits for multiple events, I cannot point to something specific missing.
Because of the "TMethodImplementationIntercept" showing up in backtraces, FL64.exe and its Dlls seem to be written in Delphi.
how do you manage to attach lldb.exe to FL64? everytime i attach it, the program immediately terminates.... Please let me know what you did. I would liek to trace the owner of the thread that blocked the other one. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=44827 --- Comment #24 from Bernhard Übelacker <bernhardu(a)mailbox.org> --- (In reply to Armonius from comment #23)
how do you manage to attach lldb.exe to FL64? everytime i attach it, the program immediately terminates.... Please let me know what you did. I would liek to trace the owner of the thread that blocked the other one.
Hello Armonius, I have retried now with a build from current git and as far as I see lldb.exe attached as expected. With which wine build do you see this issue? (And a side note: because lldb.exe looks at it from the "Windows side", the wineprefix needs to contain the same binaries which are either in the build tree or the package directory. I use 'wine wineboot --update --force' to get them in sync.) -- 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.
http://bugs.winehq.org/show_bug.cgi?id=44827 --- Comment #25 from Armonius <manicat(a)outlook.com> --- (In reply to Bernhard Übelacker from comment #24)
(In reply to Armonius from comment #23)
how do you manage to attach lldb.exe to FL64? everytime i attach it, the program immediately terminates.... Please let me know what you did. I would liek to trace the owner of the thread that blocked the other one.
Hello Armonius, I have retried now with a build from current git and as far as I see lldb.exe attached as expected. With which wine build do you see this issue? (And a side note: because lldb.exe looks at it from the "Windows side", the wineprefix needs to contain the same binaries which are either in the build tree or the package directory. I use 'wine wineboot --update --force' to get them in sync.)
Oh I realized I was using a more recent version of FL. Apparently they have some anti-debugging tactics in more recent versiosn that doesn't allow me to attach without hooking some functions. My bad for taking so long to respond. I installed llvm and clang and base-devel with some mingw-32 packages and it crashed my system... apparently it messed with my display drivers and packages. I had to backup my entire system and reinstall CachyOS. I need to reinstall everything and try it again. I managed to backup and reinstall everything, but I have to be careful on what I install to compile wine now -- 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.
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.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla