# Vienna Ensemble VST3 crash in host

**URL:** <https://forum.juce.com/t/vienna-ensemble-vst3-crash-in-host/15542>\
**Category:** General JUCE discussion\
**Created:** [August 29, 2015, 8:25pm UTC](https://forum.juce.com/t/vienna-ensemble-vst3-crash-in-host/15542 "2015-08-29T20:25:59Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![fireplayer](https://avatars.discourse-cdn.com/v4/letter/f/48db29/32.png) [@fireplayer](https://forum.juce.com/u/fireplayer)\
**Post date:** [August 29, 2015, 8:25pm UTC](https://forum.juce.com/t/vienna-ensemble-vst3-crash-in-host/15542/1 "2015-08-29T20:25:59Z")

</div>

1. Run demo host.

2. Load an instance of&nbsp;Vienna Ensemble VST3

3. Exit host or delete the filter

4, Crash at&nbsp;component-\>terminate(); in destructor

```
    ~VST3PluginInstance()
    {
        jassert (getActiveEditor() == nullptr); // You must delete any editors before deleting the plugin instance!
       
          releaseResources();
        if (editControllerConnection != nullptr && componentConnection != nullptr)
        {
            editControllerConnection->disconnect (componentConnection);
            componentConnection->disconnect (editControllerConnection);
        }
        editController->setComponentHandler (nullptr);
        if (isControllerInitialised)    editController->terminate();
        if (isComponentInitialised)     component->terminate(); **//CRASH HERE**
```

If you bypass this you get a&nbsp;AttributeList Leak.

Any ideas?

BTW this does not happen with 64 bit version of Vienna Ensemble and&nbsp;I noticed that when the Vienna VST3 instance is loaded the edtor dissappears and then reappears.

&nbsp;

Windows 10 64 BIT

---

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\
**Post date:** [September 16, 2015, 8:33pm UTC](https://forum.juce.com/t/vienna-ensemble-vst3-crash-in-host/15542/2 "2015-09-16T20:33:09Z")

</div>

Surely you should be reporting it to the plugin authors rather than us? Nothing here suggests that it's a juce bug, does it?

---

<div class="post-metadata">

**Author:** ![fireplayer](https://avatars.discourse-cdn.com/v4/letter/f/48db29/32.png) [@fireplayer](https://forum.juce.com/u/fireplayer)\
**Post date:** [October 19, 2015, 9:04pm UTC](https://forum.juce.com/t/vienna-ensemble-vst3-crash-in-host/15542/3 "2015-10-19T21:04:13Z")

</div>

Well yes it does suggest it's a juce bug. The same plugin works with all hosts that I know of except the juce host.

I have tried everything I can to determine what the problem is, but I am not knowledgeable of VST 3.

Does it work with Tracktion?

---

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\
**Post date:** [October 19, 2015, 10:24pm UTC](https://forum.juce.com/t/vienna-ensemble-vst3-crash-in-host/15542/4 "2015-10-19T22:24:28Z")

</div>

We&nbsp;fixed&nbsp;some bugs in our VST3 implementation since you posted this,&nbsp;so it'd be worth trying again.

It's not smart&nbsp;to think in terms&nbsp;like "it works in other hosts so it's a juce bug". It'd be&nbsp;equally valid&nbsp;to say&nbsp;"Other plugins work in our host, so it's a plugin bug". But neither argument is solid, and there's no evidence in either direction for this case.

I've been doing this stuff for a _long_ time, and have seen many situations where plugins fail in just&nbsp;one host&nbsp;because of stupid mistakes that are not the host's fault at all. Is this one of those&nbsp;cases? I've no idea. But if it's crashing inside the plugin's code, then something I know for sure is that&nbsp;only the plugin devs themselves can properly debug it.