Wow, major crash!

Red Prince wrote on 1/1/2017, 5:06 PM

A while ago I set (or thought I did) the OFX_PLUGIN_PATH to point at the folder where Natron keeps its OFX plug-ins. I was puzzled why I was never presented with those plug-ins in Vegas.

I have just noticed the reason: I had named the environment variable OFX_PLUGIN_PAH (which misses a letter), so I edited it to the correct name.

Then I opened Vegas Pro 14 (212), and clicked on the Video FX tab. Yes, it listed additional effects, but it also crashed. It still offered me to send a report, so of course I did.

I tried a second time, same result. So I deleted the environmental variable, and now Vegas loads fine as before. But it is rather disappointing it lets an OFX plug-in (whichever one it was) to crash it so majorly. Shouldn’t there be some kind of a try and catch in Vegas while trying to load a third-party plug-in, so it could just see one of them causes a problem, and should just give up on that plug-in and move on without crashing? I mean, this makes it so easy for hackers to crash Vegas and a non-programmer user will have no idea why it crashes (FWIW, I wonder how many of the threads started by people who cannot even start Vegas because it crashes are caused by some third-party plug-in that just happens to be on their system).

Comments

ushere wrote on 1/1/2017, 5:52 PM

not all ofx are created equal (though they should be theoretically). i found some that work in resolve don't in vegas and vice-versa.

Red Prince wrote on 1/1/2017, 5:56 PM

Of course. That is why Vegas needs to protect itself by using the try/catch combo, which will allow it to recover from a crash.

NormanPCN wrote on 1/1/2017, 7:11 PM

Shouldn’t there be some kind of a try and catch in Vegas while trying to load a third-party plug-in, so it could just see one of them causes a problem, and should just give up on that plug-in and move on without crashing?

You would think. An OFX plug-in should never allow an exception to propagate beyond its code. Everybody and their mother can write an OFX plug-ins and one should not trust them to do the right thing.

Heck even the good old Windows BSOD is a catch everything handler for kernel mode code that let an exception propagate it should not have let propagate.

(FWIW, I wonder how many of the threads started by people who cannot even start Vegas because it crashes are caused by some third-party plug-in that just happens to be on their system).

I've not hand plug-in problems with Vegas. I know NewBlue Titler Pro hangs trying to load OFX plug-ins. Their fix was for me to rename/remove their OpenFX bridge DLL, thus removing all OFX support.

Red Prince wrote on 1/1/2017, 8:16 PM

Their fix was for me to rename/remove their OpenFX bridge DLL, thus removing all OFX support.

That’s kind of odd. 🙃

set wrote on 1/1/2017, 9:46 PM

Their fix was for me to rename/remove their OpenFX bridge DLL, thus removing all OFX support.

That’s kind of odd. 🙃

That's equal to Resolve where it similarly disable all OFX support on the next start if found one ofx troubling on the previous run.

The default installation path is C:\Program Files\Common Files\OFX\Plugins

Red Prince wrote on 1/2/2017, 10:16 AM

That's equal to Resolve where it similarly disable all OFX support on the next start if found one ofx troubling on the previous run.

It’s still odd. A simple solution is to catch the problem and disable support for the particular OFX plug-in that causes problems. And still leave the option to the user to re-enable it (this would help a plug-in developer who is testing his plug-in in Vegas, finds and fixes a problem, and tests again).

set wrote on 1/2/2017, 7:25 PM

The 'manual way' to do this is to prepare another folder, let's say 'Plugins_OFF' besides 'Plugins', and move the possible trouble OFXs... check one by one...

Red Prince wrote on 1/2/2017, 10:22 PM

Well, it’s not important enough for me to go through the manual way.