Conversely, when you change to a Release build the compiler will make choices to create executable machine code that is as efficient as possible without any consideration for debugging. Examples of compiler optimizations include (but are not limited to):

The net effect of these optimizations is that debugging your application using the original source code will feel very unreliable. The most common behaviors that you will see when trying to debug optimized code are:

The easiest way to avoid the complications that come with debugging optimized code is to compile your application using a Debug build whenever possible. However, this is not always possible so there are a few other things that you can do if you must debug a Release build.

For statically compiled languages like C++, determine if the compiler has any options for recording optimization information and/or selectively de-optimizing certain portions of the code. For example, with the Microsoft Visual C++ compiler the /Zo flag will record variable optimization information that the Visual Studio Debugger can use to obtain the values for inspection in some cases. Additionally, if you are debugging optimized builds because you need application to run at speeds only provided by the optimized build, you can selectively tell the compiler not to optimize individual functions using #pragma optimize(“”,off)

.NET applies optimizations in two phases. First, when the source code is compiled to the Intermediate Language (IL) that is stored in the binary. Second, the JIT compiler applies optimizations when it compiles the IL to machine code. The Visual Studio debugger includes an option that will tell the JIT compiler to not apply optimizations to any modules that are loaded after the debugger is attached (so if you are launching the process it will not apply any optimizations to any binaries). In Visual Studio 2015 this option is off by default but if you must debug an application compiled Release, you can turn it back on under Debug -> Options and check “Suppress JIT optimizations on module load (Managed only)”.

In versions of Visual Studio prior to 2015 this option was enabled by default.  We however chose to change the default in Visual Studio 2015 to disable the option for several reasons:

As I covered above, compilers change the structure and layout of your code while applying optimizations. For example, take the C# console application below. When I start debugging, none of my breakpoints are hit in the Release build!

To successfully debug this, I set a breakpoint on line 19 (the first line in the method) which does hit. Once I am in a break state I right click in the editor and choose “Go To Disassembly” to open the Disassembly window overlaid with the corresponding source code. In this window, I can step through the actual instructions executing and even use breakpoints as I would in the standard source code editor.

While the disassembly is a lot more verbose and a little harder to understand, this is an accurate representation of what is executing so you won’t encounter issues with erratic stepping and breakpoint behavior.

Debugging optimized code can be tricky and hard to do, so when possible you should try to use Debug builds. If you must debug optimized builds, I covered a few tricks to try in this blog post to improve your experience. As we continue to evolve the compilers and debugger in Visual Studio, we’d love to hear from you how often you need to debug optimized code, what scenarios you need to do this in, and how important it is to you for us to continue to improve capability. Let me know below in the comments section, through Visual Studio’s Send a Smile tool, or via Twitter.