VST module loading crash: sign of memory corruption, or bad module loading practice?

My open source looper is making progress towards being able to support multiple plugins, and dynamically created and removed plugin instances.

But in trying to add in a full effect graph with support for recording the output of an effect chain into a loop, I seem to have destabilized things rather significantly. Specifically, I just had this crash on the first time I tried to load a plugin (which has loaded very well many times in slightly earlier versions of my app):

 	ntdll.dll!RtlReportCriticalFailure()	Unknown
ntdll.dll!RtlpHeapHandleError()	Unknown
ntdll.dll!RtlpHpHeapHandleError()	Unknown
ntdll.dll!RtlpLogHeapFailure()	Unknown
ntdll.dll!RtlpLowFragHeapAllocFromContext()	Unknown
ntdll.dll!RtlpAllocateHeapInternal()	Unknown
ntdll.dll!EtwpAllocateRegistration()	Unknown
ntdll.dll!EtwNotificationRegister()	Unknown
ntdll.dll!EtwEventRegister()	Unknown
comdlg32.dll!McGenEventRegister()	Unknown
comdlg32.dll!DllMain()	Unknown
comdlg32.dll!__DllMainCRTStartup()	Unknown
ntdll.dll!LdrpCallInitRoutine()	Unknown
ntdll.dll!LdrpInitializeNode()	Unknown
ntdll.dll!LdrpInitializeGraphRecurse()	Unknown
ntdll.dll!LdrpInitializeGraphRecurse()	Unknown
ntdll.dll!LdrpPrepareModuleForExecution()	Unknown
ntdll.dll!LdrpLoadDllInternal()	Unknown
ntdll.dll!LdrpLoadDll()	Unknown
ntdll.dll!LdrLoadDll()	Unknown
KernelBase.dll!LoadLibraryExW()	Unknown
    [Inline Frame] NowSoundLib.dll!juce::DynamicLibrary::open(const juce::String &) Line 291	C++
NowSoundLib.dll!juce::ModuleHandle::open() Line 664	C++
NowSoundLib.dll!juce::ModuleHandle::findOrCreateModule(const juce::File & file) Line 619	C++
NowSoundLib.dll!juce::VSTPluginFormat::createPluginInstance(const juce::PluginDescription & desc, double sampleRate, int blockSize, void * userData, void(*)(void *, juce::AudioPluginInstance *, const juce::String &) callback) Line 3577	C++
NowSoundLib.dll!juce::AudioPluginFormat::createInstanceFromDescription(const juce::PluginDescription & desc, double initialSampleRate, int initialBufferSize, juce::String & errorMessage) Line 131	C++
[Inline Frame] NowSoundLib.dll!juce::AudioPluginFormatManager::createPluginInstance(const juce::PluginDescription & rate, double blockSize, int) Line 127	C++
[Inline Frame] NowSoundLib.dll!NowSound::NowSoundGraph::CreatePluginProcessor(NowSound::PluginId) Line 785	C++
NowSoundLib.dll!NowSound::SpatialAudioProcessor::AddPluginInstance(NowSound::PluginId pluginId, NowSound::ProgramId programId, int dryWet_0_100) Line 76	C++
[Managed to Native Transition]
 NowSoundWinFormsApp.exe! NowSoundWinFormsApp. InputRow.EffectComboSelectedIndexChanged(object sender, System.EventArgs e) Line 104	C# 	 
System.Windows.Forms.dll! System.Windows.Forms.ComboBox. OnSelectedIndexChanged(System.EventArgs e)	Unknown
System.Windows.Forms.dll!System.Windows.Forms.ComboBox.WmReflectCommand(ref System.Windows.Forms.Message m)	Unknown
System.Windows.Forms.dll!System.Windows.Forms.ComboBox.WndProc(ref System.Windows.Forms.Message m)	Unknown
System.Windows.Forms.dll! System.Windows.Forms.NativeWindow. DebuggableCallback(System.IntPtr hWnd, int msg, System.IntPtr wparam, System.IntPtr lparam)	Unknown

I thought this might be due to the plugin itself, but this crash makes it pretty clear the plugin didn’t even get to run, so there’s some issue here independent of the specific plugin.

Is this kind of a crash likely due to some other mysterious memory problem somewhere? Or is it not best practice to be dynamically loading plugins in the middle of a session? Should I make sure I create an instance of each plugin just to avoid LoadModule calls at runtime, or is there some way to force the KnownPluginList or other JUCE type to preload the necessary modules?

I could just create an instance of the plugin and keep it around… if there is no other way, I may do that, but this particular plugin has a 250MB memory footprint – see separate thread on that – so I would have to cache and reuse it, adding complexity I’d rather avoid.

Thanks for any insight.

Self-reply: it turns out this was a float buffer that was half as big as the data I was writing into it, causing arbitrary hilarity. Sorry for taking up forum time with this. Good old unmanaged code…

XCode has the Address Sanitiser to find those kind of errors… I am not sure, but would assume, there is a tool on Windows as well…

Google found some positive hints: https://stackoverflow.com/questions/47711390/address-sanitizer-like-functionality-on-msvc