This issue may have not been related to 64-bit plugins only, but commenting out the code that checks if the plugin’s handle is that of a window, and destroys it, does the trick (in this case anyways)… As it was, the handle of the MLimiter plugin’s instance was getting nulled, so the next time around in openPluginWindow(), the plugin handle would be 0 (see line 2238).
//juce_VSTPluginFormat.cpp - VSTPluginWindow
void closePluginWindow()
{
if (isOpen)
{
#if ! (JUCE_MAC && JUCE_SUPPORT_CARBON)
JUCE_VST_LOG ("Closing VST UI: " + plugin.getName());
isOpen = false;
dispatch (effEditClose, 0, 0, 0, 0);
stopTimer();
#if JUCE_WINDOWS
//#pragma warning (push)
//#pragma warning (disable: 4244)
//if (pluginHWND != 0 && IsWindow (pluginHWND))
// SetWindowLongPtr (pluginHWND, GWLP_WNDPROC, (LONG_PTR) originalWndProc);
//#pragma warning (pop)
//if (pluginHWND != 0 && IsWindow (pluginHWND))
// DestroyWindow (pluginHWND);
pluginHWND = 0;
#elif JUCE_LINUX
pluginWindow = 0;
pluginProc = 0;
#endif
#endif
}
}