Thanks wiess, I also had the same problem today with NUMEROUS tables getting that same error. I did what you posted above & all seems good now. 
I get the same thing, if i launch vpx 10.6.exe
Is just antivirus doing as it is designed to do, and i dont have that exe exceptioned
If you use VP9, just make sure to exception your VP9 exe the same way as i showed vpx
and if you keep your vp9 tables in a separate folder, make sure to do a *.vbs exception for that folder path, in case you use any external table scripts
Personally, i dont use external table scripts.
If i get one of thalamus's updated scripts for a table, i will run it once as an external script to make sure it is what i want, and then if it is
i open it in notepad++, and then delete the file itself, and copy it from notepad++
then i open the table again, in the editor, and i replace the stock script, and i usually update the table info to reflect what script i updated the table to.
That way, i only have the vbs files that come with vpx
It isnt free to have a program listed for specific exceptions, and due to the nature of how VPX works, MS possibly may not do it anyways
from their side, the risk is too great, putting them at fault, and they have taken a lot of heat over the years for being too lax in those areas.
So instead, they give ways for a person who knows enough to set up their own in depth exceptions.
The reason it did not work when you did a normal exception is because you need 2 kinds of exceptions for VPX itself
1) you have to exclude the process, which tells it that it does not need to poke its fingers into VPX when it is running
This helps defender not kill the table as the vb script is all internal in that regard
2) you exclude the exe itself as a path, which looks funny in writing, but that that does is let AV basically know to ignore checking it for loading an external file
in this case, the VBS files that it calls with the execute external.
Otherwise what happens is defender lets it run the table script, up to the point that it calls up an additional external VBS.
Otherwise it will shut it down as technically that is a security risk.
It is VBS so basically, one could code it to do literally anything, erase files, email files, log keys, invite someone to remote in, or even serve to simply go and download
something much nastier and install it.
Which is why i say, DO NOT get tables, no matter how tempting, from any site that is not reputable
VPForums, VPUniverse and a few of the other sites that have been around a long time.
If in doubt, ask someone here like thalamus or outthere etc.
3) You exception the tables and scripts path's with *.vbs in the path.
This is so defender knows not to go about blocking or deleting your script files themselves
The scripts contain actions that can and will flag them as dangerous
For example some tables will create and write to a file, like how EM tables save high scores in a text file
Or like controller or bs2, they call up DLL's
And things like that, this this tells defender to leave them alone, which is why you dont want joe blow's random pinball scripts
vpforums and vpu have people that look at every upload for maliciously made crap
I am sure the other good sites do as well, i just can not attest to it as i dont really use them, i mostly get tables from here, and once in a while VPU
The thing with VB Script is, it is plain text, you can not hide anything in it, but most people are not really capable of reading it and knowing if they just saw something malicious or not
hence AV being so protective