No idea what to look at here but subject says it all.
I don’t have the solution to your problem, but I will mention that uninitialized memory is handled differently in debug versus release builds. Is it possible that somewhere in your audio process block you are relying on the state of an uninitialized variable?
Good luck!
I will check that thanks.
Tricky, needing to debug release is awkward.
I’ve used a Juce’s logger to check vars for NaN a couple of times. For me It’s sometimes the order of things I mixed up with, which can cause uninitialised vars.
Juce’s file Logger…
//class member:
std::unique_ptr<FileLogger> logger;
// In constructor...
logger = std::unique_ptr<FileLogger>(FileLogger::createDateStampedLogger(logLocation, "mylog", ".txt", "Plug-in logging"));
// Writing to Logger...
if (isnan(myVar) logger->logMessage("myVar is NaN"); //...any Juce string
// You can log anything you want in Release, which is pretty handy.
People coming from higher level languages like JS tend to forget variables are not set to zero when declared in C++. They can be anything non float, like 0xFFFFFFFF. NaN’s can cause a cascade of errors, if included in calculations.
Here’s what I do. I have a function that works on AudioBuffer or AudioBlock that returns true if it detects rogue float values (nan, inf etc). Assert on that at the end of processBlock to catch them in debug.
Then I have a similar function that detects rogue values but zeros them out. Also at the end of processBlock, but makes it into release builds. Just as a safety net.
generates a continuous sine wave in processblock and ignores everything else. If the wave is heard, the problem is somewhere in your application. Just ignore parts of your application until you hear something, continue doing this until you locate the problem.
You could of course, if you can, just comment out various DSP loop function calls until it works! 
But in the end it’s nearly always lack of initialisation that causes issues with debug/release differences.