I'm having this issue too - on VEP 7 on OSX High Sierra.
In my case it seems to only happen if I launch VEP by double clicking on my default VEP server startup file (.vesp64) which loads my three VEP instances into VEP server - all instances being 100% KONTAKT libraries.
Now here's something that migh provide a clue to a solution:
I gather that VEP is written in JUCE. Several years ago I actually had a C++ project of my own - which was in fact - also a plugin server - and it was written in JUCE. The project has been temporarily shelved but got to 90% - ish feature complete as far as the main engine guts was concerned but GUI work was unfinished and needed redoing. But I came across a very similar issue I and people here are having whenever my C++ plugin server app was set up to automatically load my KONTAKT instances on bootup.
It resulted me in carrying out months of email discussions with the JUCE developer team - and in the end the issue only got resolved by Julian Storer himself suggesting a solution which when i implemented it solved the problem in my host server app.
The issue in my case had to do with how the JUCE App went through its startup process and involved a need in the end to introduce a timer delay in order to let the JUCE framework go through its entire initialisation process on bootup for the GUI run loop not to clash with initialisation code and something in KONTAKT that caused this hang. - By means of the timer delay - the actual plugin loading proces only started after that. I think as i recall that the issue was particular to OSX and thus any solution here would not apply to Windows. ( my code was onlty at this time being developed for OSX )
The VEP team might want to contact Julian Storer and mention my name dan stenning - and maybe Jules can point the VEP team in the right direction. Or the VEP dev team can PM me.