Plugin crashes in Windows high-DPI mode


in both hosts, Studio One and Wavelab, our QA encountered severe problems with VSTGUI’s high-DPI implementation. Here is one example for Wavelab:

  • Open Wavelab on a computer connected to two different monitors. The first one is scaled to 150 % (high-DPI) and the other one 100 % (non high-DPI).
  • Instantiate a VSTGUI 4.6 based plugin and open the editor UI.
  • Move the editor UI from one screen to the other.
    -> Host crashes.

A similar problem occurs in Studio One, when moving a plugin UI on those two screens back and forth. We have reproduced this with our internal plugins and with Fuse Audio Labs’ products. All in all, Windows high-DPI support generally works well, but with a set-up of two different screens it can become instable. What do you suggest, Arne?



EDIT: I have to correct myself. In Studio One there is not a crash happening, so the problem is not as severe as it sounds in my initial post. It is more a mouse cursor inaccuracy and possible loss of control over the editor window.

Hi Joscha,

Thanks for the heads up.I’ll try to reproduce and get back to you with my findings asap. In which version of windows does this occur?
Can you try what happens if you undefine the VST3_CONTENT_SCALE_SUPPORT macro in the SDK examples (not saying this is a solution, just trying to figure out what’s going on)?


I have an update regarding the issues in Studio One: The bug is also reproducible with Presonus’ VST3 plugins. So, this seems to be a host bug. Probably, the Wavelab bug is also a host problem.

Is this also reproducible with the SDK plug-ins ? If yes, then I can trigger the Wavelab team to look at it.


Hey Arne,

actually, it is also reproducible with AGain (VST SDK 3.69). Our QA has been able to reproduce the crash with the example plug-in as well. It did not happen directly, but after some moving from one monitor to the other back and forth.



I will investigate this. Can you please tell me the WaveLab version you are using?


I am not sure what the problem is but I have also experienced a crash of the host at one point because of an assert in the VSTGUI code. The point being that when it happened, there was a report on the cli where I had started my DAW so I knew what the problem was (in my case it was CControl::endEdit L154 => vstgui_assert(editing >= 0) and using a control that comes with the sdk not my own… so there is at a bug somewhere which triggers this assert if you click too fast…)

While developing I always start my DAW from the command line that way I get all my debugging/info statements and assert logs right in that window…

This is how I start the one I use (macOs): /Applications/Reason\ 9/

I know this isn’t a solution but it may give you some ideas on troubleshooting


Hi René,

this has been tested with Wavelab 9.5.25.