# Best practice to track down a release-build-only bug under Visual Studio
**URL:** https://forum.juce.com/t/best-practice-to-track-down-a-release-build-only-bug-under-visual-studio/33525
**Category:** Windows
**Created:** [May 22, 2019, 11:23am UTC](https://forum.juce.com/t/best-practice-to-track-down-a-release-build-only-bug-under-visual-studio/33525 "2019-05-22T11:23:26Z")
**Posts on this page:** 15
**Page:** 1
### Author:  [@PluginPenguin](https://forum.juce.com/u/PluginPenguin)
#### Post date: [May 22, 2019, 11:23am UTC](https://forum.juce.com/t/best-practice-to-track-down-a-release-build-only-bug-under-visual-studio/33525/1 "2019-05-22T11:23:26Z")
I’m doing most of my work on Mac/Linux. However I’ve ported an application to Windows, which runs as excepted as a debug build but outputs no signal when compiled as a release build. On Mac or Linux I’d probably start printing some variable states from within the DSP callback with `printf` to get an idea what’s going on, however a Windows GUI application gives me no console per default.
Before I start to create a console for this purpose (I know this is possible) - is there any quick way or neat trick to debug a release build in Visual Studio I’m not aware of?
---
### Author:  [@xenakios](https://forum.juce.com/u/xenakios)
#### Post date: [May 22, 2019, 11:37am UTC](https://forum.juce.com/t/best-practice-to-track-down-a-release-build-only-bug-under-visual-studio/33525/2 "2019-05-22T11:37:48Z")
You can use Juce’s Logger::writeToLog which will on Windows use the OutputDebugStr API instead of printf. Then if you start debugging (even a release build) in Visual Studio, those messages can be seen in the “Output” pane of VS. Alternatively you can use the DebugView.exe program to view the messages from OutputDebugStr calls. Obviously you should be very careful when outputting messages from within the audio processing thread, things can get clogged up and you may get side effects that just make it harder to understand your original problem.
> **[DebugView - Windows Sysinternals](https://docs.microsoft.com/en-us/sysinternals/downloads/debugview)**
>
> This program intercepts calls made to DbgPrint by device drivers and OutputDebugString made by Win32 programs.
---
### Author:  [@alatar](https://forum.juce.com/u/alatar)
#### Post date: [May 22, 2019, 12:16pm UTC](https://forum.juce.com/t/best-practice-to-track-down-a-release-build-only-bug-under-visual-studio/33525/3 "2019-05-22T12:16:27Z")
You can tell Visual Studio to compile a release build with Debug variables.
That means: you can look at the value of variables, even when in Release build.
There is an option for this in the Projucer. See attached screenshot. Or else you can activate it directly from within Visual Studio.
---
### Author:  [@mcmartin](https://forum.juce.com/u/mcmartin)
#### Post date: [May 22, 2019, 12:26pm UTC](https://forum.juce.com/t/best-practice-to-track-down-a-release-build-only-bug-under-visual-studio/33525/4 "2019-05-22T12:26:20Z")
Release configuration only bugs are usually due to uninitialized variables. The Debug runtime zeroes all memory before its usage, but the Release runtime doesn’t and you usually get garbage. Depending on the size of the project, it might not be feasible to inspect every variable creation, but the more you use `auto` and in-class member initialization, the safer it becomes.
---
### Author:  [@reuk](https://forum.juce.com/u/reuk)
#### Post date: [May 22, 2019, 12:44pm UTC](https://forum.juce.com/t/best-practice-to-track-down-a-release-build-only-bug-under-visual-studio/33525/5 "2019-05-22T12:44:15Z")
> [@McMartin](#):
>
> Release configuration only bugs are usually due to uninitialized variables.
Further to this, uninitialised variables on Windows will often be uninitialised on Mac/Linux too, so you might be able to track them down with Undefined Behaviour Sanitizer on one of those platforms.
---
### Author:  [@Toddler-Boy](https://forum.juce.com/u/Toddler-Boy)
#### Post date: [May 22, 2019, 3:56pm UTC](https://forum.juce.com/t/best-practice-to-track-down-a-release-build-only-bug-under-visual-studio/33525/6 "2019-05-22T15:56:39Z")
> [@McMartin](#):
>
> The Debug runtime zeroes all memory before its usage
No, it doesn’t zero them, it initializes all their bytes to “0xDD”. So SHORTs become 0xDDDD, pointers are 0xDDDDDDDD etc.
This is international to trigger buggy behavior in debug builds.
---
### Author:  [@t0m](https://forum.juce.com/u/t0m)
#### Post date: [May 22, 2019, 4:23pm UTC](https://forum.juce.com/t/best-practice-to-track-down-a-release-build-only-bug-under-visual-studio/33525/7 "2019-05-22T16:23:01Z")
That’s not true in the general case. Is it something you can opt into?
---
### Author:  [@Toddler-Boy](https://forum.juce.com/u/Toddler-Boy)
#### Post date: [May 22, 2019, 7:21pm UTC](https://forum.juce.com/t/best-practice-to-track-down-a-release-build-only-bug-under-visual-studio/33525/8 "2019-05-22T19:21:05Z")
With MSVC that has been true since I’ve been using it (VC4) over twenty years ago. I’m not sure about Xcode (so clang/gcc).
Here is some condensed info:
[https://www.codeguru.com/cpp/w-p/win32/tutorials/article.php/c9535/Inside-CRT-Debug-Heap-Management.htm](https://www.codeguru.com/cpp/w-p/win32/tutorials/article.php/c9535/Inside-CRT-Debug-Heap-Management.htm)
---
### Author:  [@matt](https://forum.juce.com/u/matt)
#### Post date: [May 22, 2019, 11:11pm UTC](https://forum.juce.com/t/best-practice-to-track-down-a-release-build-only-bug-under-visual-studio/33525/9 "2019-05-22T23:11:09Z")
Might be worthwhile to run Visual Studio’s code analysis; it’s pretty good at finding things like uninitialized variables.
You’ll get a bunch of false positives with some of the ancillary libraries included with JUCE like pnglib, so you’ll need to filter the results a bit.
Matt
---
### Author:  [@t0m](https://forum.juce.com/u/t0m)
#### Post date: [May 23, 2019, 7:50am UTC](https://forum.juce.com/t/best-practice-to-track-down-a-release-build-only-bug-under-visual-studio/33525/10 "2019-05-23T07:50:31Z")
@Toddler-Boy - with MSVC you get special values written when you use malloc, but not if you use an uninitialised variable.
```
auto* i = (int*) malloc (sizeof (int));
assert (*i == 0xCDCDCDCD); // Freshly initialised memory
free (i);
assert (*i == 0xDDDDDDDD); // Dangling pointer
int j;
std::cout << j << "\n"; // Prints something undefined
```
Clang and gcc fairly reliably set the special values to zero. I don’t know if that is guaranteed.
---
### Author:  [@xenakios](https://forum.juce.com/u/xenakios)
#### Post date: [May 23, 2019, 9:12am UTC](https://forum.juce.com/t/best-practice-to-track-down-a-release-build-only-bug-under-visual-studio/33525/11 "2019-05-23T09:12:16Z")
Which Visual Studio version you used for testing this?
```auto
int i;
std::cout << i << "\n";
```
Here it doesn’t even compile on Visual Studio 2017 15.9.11, the compiler immediately notices it’s a use of an uninitialized variable!
If I do a class and construct it on the stack that uses an uninitialized member :
```auto
class Foo
{
public:
Foo()
{}
void bar()
{
std::cout << std::hex << m_i;
}
int m_i;
};
```
The compiler doesn’t catch that, nor does the debugger during runtime, but I get a consistent output of “CCCCCCCC” out of that.
---
### Author:  [@railjonrogut](https://forum.juce.com/u/railjonrogut)
#### Post date: [May 23, 2019, 9:23am UTC](https://forum.juce.com/t/best-practice-to-track-down-a-release-build-only-bug-under-visual-studio/33525/12 "2019-05-23T09:23:35Z")
> **[Magic number (programming)](https://en.wikipedia.org/wiki/Magic_number_(programming))**
>
> In computer programming, the term magic number has multiple meanings. It could refer to one or more of the following:
> The term magic number or magic constant refers to the anti-pattern of using numbers directly in source code. This has been referred to as breaking one of the oldest rules of programming, dating back to the COBOL, FORTRAN and PL/1 manuals of the 1960s. The use of unnamed magic numbers in code obscures the developers' intent in choosing that number, increases opportunities for su...
Check out **Magic Debug Values**
Rail
---
### Author:  [@t0m](https://forum.juce.com/u/t0m)
#### Post date: [May 23, 2019, 9:45am UTC](https://forum.juce.com/t/best-practice-to-track-down-a-release-build-only-bug-under-visual-studio/33525/13 "2019-05-23T09:45:36Z")
> [@Xenakios](#):
>
> Which Visual Studio version you used for testing this?
VS 2019.
Like it or not, it’s valid C++ so it will compile. I assume you’re building with warnings enabled and “warnings are errors” selected. In this simple case the compiler can tell that it’s an uninitialised variable, but if you make it more complicated then the compiler can miss these things.
---
### Author:  [@PluginPenguin](https://forum.juce.com/u/PluginPenguin)
#### Post date: [May 23, 2019, 11:45am UTC](https://forum.juce.com/t/best-practice-to-track-down-a-release-build-only-bug-under-visual-studio/33525/14 "2019-05-23T11:45:20Z")
Wow, this discussion got quite far since my initial post yesterday 😃
Anyway, you all shared a lot of interesting input, but mainly @Xenakios first answer was the solution to my question.
By the way, it turned out that the error was not based on an uninitialized variable but on the mis-use of a third party API which I could indeed spot with some print-debugging 😉
---
### Author:  [@zabukowski](https://forum.juce.com/u/zabukowski)
#### Post date: [May 23, 2019, 12:59pm UTC](https://forum.juce.com/t/best-practice-to-track-down-a-release-build-only-bug-under-visual-studio/33525/15 "2019-05-23T12:59:50Z")
99% of my non-working release builds were caused by unitialized variables 🙂