Plugins crashing

[sirpas]

A *more recent* issue I have had since upgrading to the latest version of MB32C 64bit has been plugins crashing the session.

I have purchased various XT/ACE plugins or just try to use any from this series. When I do, it loads the windows the plugin would be shown in and then stays black followed by the software crashing.  No errors are noted that I can see.

Also, Waves Abbey Road Reverbs and Plates crash the system too. 

There's no rhyme or reason I can find and all of my other very graphic-intensive plugins like those from Plugin Alliance or Izotope are stable.  I have the latest GPU drivers on the video side and those haven't caused issues with anything on my computer.

MB32C ver 9.2.172
Windows 11
AMD GPU drives are latest - v24.2.1

How can I debug these issues?  I bought several of these XT plugins and love them, and I really need them to work.

Thank you for the help.

[Dingo]

Assuming things were working pre the upgrade... have you considered trashing your preferences and starting a clean setup ?

https://rsrc.harrisonconsoles.com/mixbus...ser-topics

[BSchmitty]

If you have a different DAW, do the waves plugins work? Mine were dependant on graphics settings being adjusted.

Did you update the graphic drivers recently? 

I suggest adjusting the graphic card setting to 'performance' if it's not already. Maybe try a few other settings related to openGL(if any)  , lowering antialias, or off. Just take note of what is changed so you an change it back.

[Monofin]

Hi there, long term Mixbus user here, first time poster:
I've picked up a similar crash, and spent sometime debugging my version of it:


32Cv8, ProTools, Ardour and Reaper don't exhibit the same issue, but 32C v9.2.172 definitely does - I don't have an earlier installer of v9 available to biscect the issue though.

All the instability described below does *not* happen with the same plugins on the same install on the same version of windows when using the current Mixbus 32C v8.

I've switched on full heap checking on Windows for the app to try to pull this apart, and got some way into it.
I can reproduce a crash by starting a completely blank session, then allocating something like Abby Road Chambers or CLA Bass plugin to a mixbus.

Weird Symptom: In many cases this immediately causes continual random clicks in the output audio (regardless of output device, I've even tried it with windows MME....).
These clicks happen regardless of the actual mixbus routing and any mixer settings including muting: That points to output buffer corruption.
The clicks only seem to occur if some non-zero audio data has been sent through the system.

- Side note: changing the latency compensation from 101 samples to 100 immediately removes the clicks - this points to something like an audio buffer overrun/out of bounds write caused by some mis-calculation or possibly off-by-one.

Even Weirder bit:
It only happens on i9 and Xeon based units so far - not on my i7 systems.
I've trashed preferences, reinstalled Windows (10 and 11), reinstalled plugins, and it seems consistent.
I've swapped GPUs (AMD, Nvidia, Intel) and whole machines, and it seems consistent.

It seems that there's some form of silent heap corruption happening, relating to the Mixbus specific channel processing, and particularly on the mixbusses themselves.

The same/similar symptoms of crash (heap corruption on free())seems to happen if you bounce multiple channels to disk with plugins disabled on startup on a session that contains these plugins : Its not as repeatable, though.

The crash happens at the point when some memory is free() (released), and Windows detects heap corruption because the allocation check bitpattern (written after the actual size of the allocation, in order to catch this situation) has been corrupted.

This kind of crash only happens *after* the actual corruption has happened, and therefore can be in any function - its a booby trapped bit of memory. It might not even crash under certain access patterns.

Full heap checking on Windows can't catch an errant write in this case, because its only writing the trailing bit pattern of the allocation - and it seems Windows's full page heap allocator can only catch it with a trap if it writes over the end of the page boundary. To catch the actual source you'd need to re-verify every allocation on the heap and it's trailing bit pattern after every memory write - not feasible.

I've also observed crashes when adding and removing plugins to individual channels, and its almost 100% on mixbuses - I can do this hundreds of times on v8 on the same machine with the same plugins with no issues at all.

So far I'm wondering if it's a race condition on systems with high memory bandwidth, but it looks more like a buffer overrun issue that is scribbling on the heap, related to one of the updated v9 Harrison channel processing plugins.
I've reduced 32C to a single CPU, and even used BIOS to turn off all but one CPU, and the results are the same (though the bounce to disk is more reliable, the plugin on a mixbus issue remains).

I've been forced to revert to 32C v8, which is frustrating, as I prefer the 32C v9 layout.

[johne53]

Welcome to the forum Monofin and thanks for such a detailed report. You seem quite tech savvy so if you're familiar with the old (DOS style) commands you can open a Windows Command Prompt and navigate to the folder where Mixbus got installed (typically somewhere like:- C:\Program Files\Mixbus32C-9\bin )

Now launch Mixbus by typing it's name. You should then see some text appear in the Command window and hopefully (when it crashes) the text might help Harrison to identify what went wrong.

[Edit...] One other thing you could try:- Window->Preferences->Show->Plugins->GUI

Find the option called Closing a Plugin GUI window then set it to only hides the window. Let us know if that helps.

[Monofin]

Hi there: Thanks for the welcome and the advice! I'll report back ASAP.

[Monofin]

Output at console:
------
PS C:\Program Files\Mixbus32C-9\bin> .\Mixbus32C.exe
PS C:\Program Files\Mixbus32C-9\bin> ARDOUR_DATA_PATH not set in environment
Mixbus32C9.2.172 (built using 9.2-172-gc80d313a86 and GCC version 8.3-posix 20190406)
Crash Log: C:\Users\ebeas\AppData\Local\Mixbus9\CrashLog\Mixbus32C-9.2.172-crash-1712402904.txt
Mixbus32C: [INFO]: MMCSS Initialized
Mixbus32C: [INFO]: Your system is configured to limit Mixbus32C to 2048 open files
ARDOUR_CONFIG_PATH not set in environment
Mixbus32C: [INFO]: Loading system configuration file C:\Program Files\Mixbus32C-9\share\ardour9\system_config
Mixbus32C: [INFO]: Loading user configuration file C:\Users\ebeas\AppData\Local\Mixbus9\config
Mixbus32C: [INFO]: CPU vendor: GenuineIntel
Mixbus32C: [INFO]: AVX capable processor
Mixbus32C: [INFO]: AVX with FMA capable processor
Mixbus32C: [INFO]: AVX512F capable processor
Mixbus32C: [INFO]: CPU brand: Intel® Core™ i9-7940X CPU @ 3.10GHz
Mixbus32C: [INFO]: Using AVX512F optimized routines
Mixbus32C: [INFO]: Loading plugin meta data file C:\Program Files\Mixbus32C-9\share\ardour9\plugin_metadata\plugin_tags
Mixbus32C: [INFO]: Loading plugin statistics file C:\Users\ebeas\AppData\Local\Mixbus9\plugin_metadata\plugin_stats
Mixbus32C: [INFO]: add_lrdf_data 'C:\Users\ebeas\AppData\Local\Mixbus9\rdf;C:\Program Files\Mixbus32C-9\share\ardour9\rdf'
Mixbus32C: [INFO]: read rdf_file 'file:///C:/Program%20Files/Mixbus32C-9/share/ardour9/rdf/ardour-presets.n3'
Mixbus32C: [INFO]: Loading default ui configuration file C:\Program Files\Mixbus32C-9\share\ardour9\default_ui_config
Mixbus32C: [INFO]: Loading user ui configuration file C:\Users\ebeas\AppData\Local\Mixbus9\ui_config
Mixbus32C: [INFO]: Loading 457 MIDI patches from C:\Program Files\Mixbus32C-9\share\ardour9\patchfiles
Mixbus32C: [INFO]: Loading color file C:\Program Files\Mixbus32C-9\share\ardour9\themes\dark-mixbus32c.colors
Mixbus32C: [INFO]: Loading ui configuration file C:\Program Files\Mixbus32C-9\share\ardour9\clearlooks.rc
Mixbus32C: [INFO]: Loading bindings from C:\Program Files\Mixbus32C-9\share\ardour9\ardour.keys
Loading ui configuration file C:\Program Files\Mixbus32C-9\share\ardour9\clearlooks.rc
Announcement string is too long (probably behind a proxy).
Set cursor set to default
Setting time domain
Mixbus:  Screen height is 1340; Font scale is 1; User-scale is 1; Suggested scale: 1.21818
-------
Nothing more.... crash happened whilst exporting stems to disk, and also when adding/deleting plugins to the mixbus. Audio was clicking as reported.
Crashlog wasn't generated (!).

----------

I do now have part of an answer though:

AVX512F routines are enabled on the Xeon/i9 machines and its only AVX+FMA on the i7's. The i7s don't click or crash for me....

(I even tried a NVMe Drive disk swap from the i7 to the i9 - after a good amount of windows thrashing, I was able to start mixbus - crashed on the i9 above, swapped back, fine on the i7 - I know its not a definitive test due to drivers differences, but I wonder if I can turn off AVX512F on the Xeon).

------
Update: Started Mixbus v9.2.172 with --no-hw-optimizations.

NO audio clicking, and no crashing either. so far.

Console Log with --no-hw-optimizations:
-------
PS C:\Program Files\Mixbus32C-9\bin> .\Mixbus32C.exe --no-hw-optimizations
PS C:\Program Files\Mixbus32C-9\bin> ARDOUR_DATA_PATH not set in environment
Mixbus32C9.2.172 (built using 9.2-172-gc80d313a86 and GCC version 8.3-posix 20190406)
Crash Log: C:\Users\ebeas\AppData\Local\Mixbus9\CrashLog\Mixbus32C-9.2.172-crash-1712404644.txt
Mixbus32C: [INFO]: MMCSS Initialized
Mixbus32C: [INFO]: Your system is configured to limit Mixbus32C to 2048 open files
ARDOUR_CONFIG_PATH not set in environment
Mixbus32C: [INFO]: Loading system configuration file C:\Program Files\Mixbus32C-9\share\ardour9\system_config
Mixbus32C: [INFO]: Loading user configuration file C:\Users\ebeas\AppData\Local\Mixbus9\config
Mixbus32C: [INFO]: No H/W specific optimizations in use
Mixbus32C: [INFO]: Loading plugin meta data file C:\Program Files\Mixbus32C-9\share\ardour9\plugin_metadata\plugin_tags
Mixbus32C: [INFO]: Loading plugin statistics file C:\Users\ebeas\AppData\Local\Mixbus9\plugin_metadata\plugin_stats
Mixbus32C: [INFO]: add_lrdf_data 'C:\Users\ebeas\AppData\Local\Mixbus9\rdf;C:\Program Files\Mixbus32C-9\share\ardour9\rdf'
Mixbus32C: [INFO]: read rdf_file 'file:///C:/Program%20Files/Mixbus32C-9/share/ardour9/rdf/ardour-presets.n3'
Mixbus32C: [INFO]: Loading default ui configuration file C:\Program Files\Mixbus32C-9\share\ardour9\default_ui_config
Mixbus32C: [INFO]: Loading user ui configuration file C:\Users\ebeas\AppData\Local\Mixbus9\ui_config
Mixbus32C: [INFO]: Loading 457 MIDI patches from C:\Program Files\Mixbus32C-9\share\ardour9\patchfiles
Mixbus32C: [INFO]: Loading color file C:\Program Files\Mixbus32C-9\share\ardour9\themes\dark-mixbus32c.colors
Mixbus32C: [INFO]: Loading ui configuration file C:\Program Files\Mixbus32C-9\share\ardour9\clearlooks.rc
Mixbus32C: [INFO]: Loading bindings from C:\Program Files\Mixbus32C-9\share\ardour9\ardour.keys
Loading ui configuration file C:\Program Files\Mixbus32C-9\share\ardour9\clearlooks.rc
Mixbus32C: [INFO]: CPU vendor: GenuineIntel
Mixbus32C: [INFO]: AVX capable processor
Mixbus32C: [INFO]: AVX with FMA capable processor
Mixbus32C: [INFO]: AVX512F capable processor
Mixbus32C: [INFO]: CPU brand: Intel® Core™ i9-7940X CPU @ 3.10GHz
Announcement string is too long (probably behind a proxy).
Set cursor set to default
Setting time domain
Mixbus: Screen height is 1340; Font scale is 1; User-scale is 1; Suggested scale: 1.21818

------

[Monofin]

Update: My plugin settings were already set to 'only hides the window' as part of my earlier debugging of the problem, that applies to the above crash as well :-)

[Monofin]

Chasing down some possible leads, I came across GCC bug #86735 (can't post URL on the forum it seems!), which points at binutils (GNU assembler) bug #23465

Digest: a version of memcpy() that is inlined and uses AVX512F generates incorrect offsets, and its a GNU Assembler bug. That would cause heap scribbling, amongst other things, only on AVX512 capable hardware.
What compiler version is used for Harrison 32C 9.1.172 I wonder? (just to rule it in/out).
----
Mixbus32C9.2.172 (built using 9.2-172-gc80d313a86 and GCC version 8.3-posix 20190406)
----
So this was the version of GCC released in 2019 - and overlaps with the period that the bug was in the wild in binutils.
There are further reports of the bug being associated with GCC 8.3 and quite a bit later up to about 2020, depending on the build environment.

So it does look quite possible that bug exists in the version of binutils 2.30/2.31 (rather than GCC itself) that may well have used to build Mixbus 32C...

[johne53]

Fortunately, disabling optimizations doesn't run Mixbus unoptimized. It only applies to certain very specific ones. We're straying a bit beyond the scope of this forum but for the most part, they'll be optimizations that get used for very repetitive tasks, such as generating waveform files. It's good to know you can fix the problem by disabling optimizations - and in practice, the drop in performance is unlikely to be something you'll notice.

[Edit...] I just looked at the Mixbus source code and it looks like AVX512 optimization only got introduced in Version 9 - or (possibly) the very last release of 8.2. So that fits in with what you're seeing. I'll flag it up to the development team