@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 beconstexpr. #3824 #4000 #4339
- Note: Programs that aren’t following the documented restrictions on binary compatibility may encounter null dereferences in
mutexmachinery. 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_CONSTRUCTORas an escape hatch.
Note is says
Programs that aren’t following the documented restrictions on binary compatibility may encounter null dereferences in
mutexmachinery
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.