Plugin crashes on non DEV machines

The latest release versions of my plugin runs perfectly on my development computer (64bit, Win10, VS2019) but it consistently crashes on other Windows machines that don’t have a development environment regardless the host application used.
The only information about the crash I manage no obtain are the windows event logs. They seem to indicate that tan access error occurs in juce_graphics.image_formats.jpeglib:

By adding the Fault offset 2a7a1c or 29de27 to the base address of the plugin module (Orbish.vst) 7FFED3B5000 in VS’s disassambler I get respectively one of the following two methods:

  • juce::jpeglibNamespace::jpeg_huff_decode
  • juce::jpeglibNamespace::sep_upsample

However, when running in debug mode and setting a breakpoint in those methods the debugger never hits them, which makes sense as I don’t use any jpeg images (only png) in the plugin.

I’m confused. How can the plugin crash on code that is not even executed?
Or maybe my way to calculate the address is wrong?

I would greatly appreciate any help with this.


You need to either statically link the C++ runtime (there’s an option for this in the Projucer), or ensure that the dynamic runtime is installed on any machine that will be used to run the plugin. Are you taking one of these approaches?

I remember that I statically linked the runtime but maybe I inadvertently changed it.
I’m checking it

Thank you for the hint.
Apparently, the option was set to default => Use DLL runtime.
Now, I changed it to ‘Use static runtime’ but still the issue remains.
The plugin crashes on machines without dev environment while it works on the one with VS installed.

Release build?

Yes, it’s a release build

Use a FileLogger and target where you could be using an invalid object (check for if the pointer or this == nullptr).

With the right amount of logging you should be able to isolate where the issue is.


In fact, I already use a lot of logging but wasn’t able to narrow it down.
I use RAII and normally log if there is an invalid object.
But I can probably still improve.

thanks @railjonrogut
More logging does the trick :slightly_smiling_face:
I think I narrowed it down to renderOpenGL() in a custom OpenGL component.
I gonna go further down that path and try to isolate the issue.

I found the problem. I have a macro SHADERS_FROM_BINARY_DATA that determines if the plugin loads shaders from files or from binary data.
In debug mode it should load from files so I can easily update and in release mode it should read from binary data.
I forgot about that and the release version then tried to load the shaders from files that are obviously not present on a user machine.

Thanks to all for helping me to narrow down this issue.