msvcp140.dll!mtx_do_lock(_Mtx_internal_imp_t * mtx, const xtime * target) Line 100
at D:\a\_work\1\s\src\vctools\crt\github\stl\src\mutex.cpp(100)
[Inline Frame] My Cool Plugin.vst3!std::_Mutex_base::lock() Line 52
at C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\include\mutex(52)
[Inline Frame] My Cool Plugin.vst3!std::unique_lock<std::mutex>::{ctor}(std::mutex &) Line 144
at C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\include\mutex(144)
My Cool Plugin.vst3!juce::WaitableEvent::wait(double timeOutMilliseconds) Line 33
at C:\Users\Adam\dev\source\my-cool-plugin\Cache\juce\092995e26ed44e4ec63040a0791aed310c6139aa\modules\juce_core\threads\juce_WaitableEvent.cpp(33)
My Cool Plugin.vst3!juce::Thread::threadEntryPoint() Line 89
at C:\Users\Adam\dev\source\my-cool-plugin\Cache\juce\092995e26ed44e4ec63040a0791aed310c6139aa\modules\juce_core\threads\juce_Thread.cpp(89)
My Cool Plugin.vst3!juce::threadEntryProc(void * userData) Line 63
at C:\Users\Adam\dev\source\my-cool-plugin\Cache\juce\092995e26ed44e4ec63040a0791aed310c6139aa\modules\juce_core\native\juce_Threads_windows.cpp(63)
[External Code]
No sign of APVTS here but I wonder if it’s just a shorter stack trace for some reason? The plugin has one custom thread (owned and started in the editor), I’m wondering if that might have something to do with this crash.
adamwilson:
No sign of APVTS here but I wonder if it’s just a shorter stack trace for some reason? The plugin has one custom thread (owned and started in the editor), I’m wondering if that might have something to do with this crash.
Yeah it looks like the same basic thing happening, seems to be the wait rather than the signal this time but it looks like the same WaitableEvent (startSuspensionEvent) however, this is part of every JUCE thread and I don’t think there has been any recent changes around this area either 
.
It feels like the kind of issue ASAN might pick up but of course if you can’t reproduce it I’m not sure what to suggest.
Have you got any sense on the rarity at which this is occurring? how many customers are seeing this?
I think it’s fairly rare but we’ve had around 10-15 reports so far. It’s hard to say how many out of the total Windows users, because it’s the ones that have an issue that complain! But none of our beta testers picked it up. Luckily one of the design team can reproduce it on his home PC so that has helped.
adamwilson:
Luckily one of the design team can reproduce it on his home PC so that has helped.
Great news!
Are they able to reproduce it with a blank session with only one instance of your plugin in the session? any particular steps that they take? I assume this happens on plugin insertion? What version of Windows are they running?
Just a thought are you statically or dynamically linking to the C++ runtime? if it’s dynamic what version of the runtime library have they got installed? and does a statically linked version make any difference?
Yes I believe the tests are with a new blank session, on Windows 11. The other user reports seem to be a mix of Windows 10 and 11 but mostly 11.
We are currently dynamically linking to the C++ runtime.
I’ll try statically linking.
Thanks for the support!
@adamwilson looking at this a little more I found the following in the Microsoft STL release notes for VS 2022 17.10
Fixed mutex’s constructor to be constexpr. #3824 #4000 #4339
Note: Programs that aren’t following the documented restrictions on binary compatibility may encounter null dereferences in mutex machinery. You must follow this rule:
When you mix binaries built by different supported versions of the toolset, the Redistributable version must be at least as new as the latest toolset used by any app component.
You can define _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR as an escape hatch.
Note is says
Programs that aren’t following the documented restrictions on binary compatibility may encounter null dereferences in mutex machinery
Looking around online I’m fairly confident this is the issue you’re seeing.
As I think we’ve already concluded, but for the sake of future readers, I think there are really only two solutions
Statically link to the C++ runtime libraries (This is my personal preference but I understand there are good reasons to avoid this)
As part of the installation process, install the redistributable that at least matches the version of the toolset used (I suspect the DAWs in this case were installing older versions)
Looks like there is a possible 3rd solution which is to define _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR, but I’m not sure if all binaries would need to define that (for example the DAW), and it would mean std::mutex couldn’t be used in anything marked constexpr, therefore I think this option should probably be avoided.
Thank you very much!!! I came across this thread purely by accident (well, google:-) and I was having the random crashes on random machines with a completely different program, but exactly the same symptoms: works for some people, crashes for others.
@anthony-nicholls it appears you have found the root of the issue.
Now I only have to solve the problem of how to get the maintainers of 4 open source packages that I use to update their code…
© Raw Material Software Limited
