# PluginDirectoryScanner best methods

**URL:** <https://forum.juce.com/t/plugindirectoryscanner-best-methods/21484>\
**Category:** Audio Plugins\
**Created:** [March 23, 2017, 11:46pm UTC](https://forum.juce.com/t/plugindirectoryscanner-best-methods/21484 "2017-03-23T23:46:15Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![railjonrogut](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/railjonrogut/32/505_2.png) [@railjonrogut](https://forum.juce.com/u/railjonrogut)\
**Post date:** [March 23, 2017, 11:46pm UTC](https://forum.juce.com/t/plugindirectoryscanner-best-methods/21484/1 "2017-03-23T23:46:15Z")

</div>

I’ve searched the forum and looked at the posts over the years… and there’s never been a definitive answer for the best way to scan for plugins and deal with any bad plugins. I don’t mean plugins that fail to validate and get added to the black-list… but plugins which can cause your scanner process to crash or hang.

The best thread I’ve found is [this one](https://forum.juce.com/t/plugin-scanning-process-always-crashes-the-application/19006/15)… but even that doesn’t have any concrete answers.

I wrote a “VeryBadPlugin” VST which is a basic ProJucer created Plugin project and I make it crash right away:

```
VeryBadPluginAudioProcessor::VeryBadPluginAudioProcessor()
#ifndef JucePlugin_PreferredChannelConfigurations
     : AudioProcessor (BusesProperties()
                     #if ! JucePlugin_IsMidiEffect
                      #if ! JucePlugin_IsSynth
                       .withInput ("Input", AudioChannelSet::stereo(), true)
                      #endif
                       .withOutput ("Output", AudioChannelSet::stereo(), true)
                     #endif
                       )
#endif
{
    crashMe();
}

 VeryBadPluginAudioProcessor::~VeryBadPluginAudioProcessor()
{
}

 void VeryBadPluginAudioProcessor::crashMe()
{
    abort();
}

```

If I scan the VST folder with this VeryBadPlugin using Tracktion… it bypasses the plugin and adds it to the black-list and the Tracktion scanner process doesn’t crash. Obviously the Tracktion scanner detects the plugin has caused a crash and restarts the scanner from where it left off… but how does it do that?

If I try and scan this same plugin using my scanner app (which also runs in a separate process) it crashes the scanner and I get a crash report.

Stepping though the code in debug with my scanner app it gets to VSTPluginInstance::constructEffect() and shows a SIGABRT at line 1581 at:

```
JUCE_VST_WRAPPER_INVOKE_MAIN

```

Can you tell us how you handle this in Tracktion?

I’ve tried using SystemStats::setApplicationCrashHandler() and that didn’t get triggered.

Thanks,

Rail

---

<div class="post-metadata">

**Author:** ![railjonrogut](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/railjonrogut/32/505_2.png) [@railjonrogut](https://forum.juce.com/u/railjonrogut)\
**Post date:** [March 24, 2017, 8:54am UTC](https://forum.juce.com/t/plugindirectoryscanner-best-methods/21484/2 "2017-03-24T08:54:56Z")

</div>

Well I found how to have Xcode not break on SIGABRT and SIGKILL

> <https://stackoverflow.com/questions/10431579/permanently-configuring-lldb-in-xcode-4-3-2-not-to-stop-on-signals>

So now at least I can test SystemStats::setApplicationCrashHandler() and have my scanner not generating a crash log.

Rail