I have been trying various different JUCE hosts and all of them have had serious problems scanning my Elicensor protected plugins from VSL. That includes AudioPluginHost, but some others as well, that I know are Juce based. my DAW’s aren’t having any problem with this, but why is JUCE unable to scan elicensor based plugins and is there a work around? I do plan to do my own hosting plugin and this will be critical for what I do as well.
I have a theory this may be specifically related to VST3 plugins only. Seems like some of the VST2 versions of the same eLicensor plugins seemed to have scanned ok and seem to work ok too. The VST3 versions appear in the list after scanning, even though the scanner complained, but trying to use them freezes the JUCE host.
My theory at the moment is that this may be related to multiple VST3 midi input ports…which JUCE hosting may not support yet. Thoughts anyone about this?
As you are the author of those plugins, have you already attached a debugger to the plugin host and did a bit of debugging to get an idea where things go wrong? Seems like you are the best person out there capable of generating this kind of information since you have the code of both JUCE and your plugins available 
Without more specific information you’ll likely get few responses to your question…
Good idea, I will try to attach and see where it gets too. May learn something. New to JUCE, so we’ll see how far I get. I was just wondering if others have already figured this out, surely I can’t be the only person trying to use JUCE hosting with elicensor plugins…but I have since determined, I think…that the problem may actually be related to VST3 and multiple midi ports. It just happens that the only plugins I have which are using multiple midi ports happen to be using elicenstor also… namely from Steinberg and VSL are the ones giving grief…and it looks like only the VST3 and AUv3 versions of the plugins appear to be failing… So I am rather suspicious at the moment that the real problem is that JUCE doesn’t fully support hosting VST3 and AUv3 when there are multiple midi ports.
As you are the author of those plugins, have you already attached a debugger to the plugin host and did a bit of debugging to get an idea where things go wrong?
But I’m not actually the author of the plugins. I am trying to host other third party plugins which are having this problem when hosted by JUCE. This happens with AudioPluginHost and several other third party hosters I have tried, same error with all of them, so the problem IMHO is inherent with JUCE. I guess there must not be very many people using these problematic plugins with JUCE hosts. At least the hosts I have tried. It could be someone has worked out a work around for them. The plugins in question include VSL and Steinberg plugins as far as I can tell its the VST3 versions and AUv3 versions causing problems. I am trying to attach to AudioPluginHost to see what i can figure out, but not entirely sure where to place a breakpoint, will try a few things though and try to step into it.
Ah sorry, I misinterpreted this line of your initial post
However learning to debug is a really helpful skill 
If the application crashes the debugger will immediately jump to the point where the crash happened. If it just hangs unresponsible but without high CPU usage, it might be something like a deadlock. In this case you can pause the application in the debugger and look through the call stacks of each thread to see if there is something that looks suspicious, e.g. if it is waiting in some initialization function call.
I have a lot of software dev experience. zero with AU/VST/JUCE or audio/midi anything, so bear with me to catch up
During plugin scanning the program isn’t crashing. its failing the plugin scanning process. Later on the plugin still appears in AudioPluginHost’s list but if I try to use it, it freezes the app. I was unable to get the debugger to stop at a place that would show anything useful that way, I looked at the stacks of all threads, nothing interesting.
I was able to step into it and find the place where the scanning failure is happening…
In the initialize method call shown below, juceVST3PluginFormat.cpp: 756 (current stable checkout from git, not developer checkout)
if (component.loadFrom (factory, info.cid))
{
if (component->initialize (vst3HostContext->getFUnknown()) == kResultOk)
{
auto numInputs = getNumSingleDirectionChannelsFor (component, true, true);
auto numOutputs = getNumSingleDirectionChannelsFor (component, false, true);
I tried to step into this method and get to this line in juceVST3PluginFormat.cpp:265
FUnknown* getFUnknown() { return static_cast<Vst::IComponentHandler*> (this); }
Trying to step into that is fruitless, probably because its a template or something I don’t know but the debugger pops all the way out to the call at line 756 mentioned above with an error reported…and attempting to step from there results in an assertion here in juce_ThreadPool.cpp:388
try
{
result = job->runJob();
}
catch (...)
{
jassertfalse; // Your runJob() method mustn't throw any exceptions!
}
I don’t know if anyone has some ideas…but this does look related to input and output midi channels as I suspected, I just don’t know anything about VST3 guts to know what if anything JUCE might be missing. I’m getting this same problem with VSL and Steinberg VST3 plugins, which are known to be setup for handling more then one midi port. They also happen to be using elicensor…and the alert dialog shown displays an error about that but the error must be getting produced by the plugin at that point…
Image of error alert: https://i.ibb.co/ZKTQdjf/error.jpg