I tend to use the release version for debugging, rather than use the debug version

I found myself at work and outside of work from time to time to support one thing to use the program releases (in any case, for Windows applications) were worth debugging. At first glance, this may contradict some people think, because people tend to think is actually more suitable for debugging the debug build (after all, it is named "Debug Build").

However, I tend to disagree with this point of view, there are several reasons:

1. Only in debugging the debug version of the case is unrealistic. Most "interesting" problems are often at the customer site or build production versions of real life appear. In many cases, we do not have enough ability to debug builds that were released to the customer or production environment.
   There is no doubt use the debugger to debug it would be easier to build, but I think, can not be effectively debug release builds a disadvantage. Always use the case to debug release build can ensure that, if you do not choose, or not feasible to reproduce the problem in trying to use the debug version, you can do this.
2. Sometimes debug build interfere with debugging. Initially, this is a very counter-intuitive concept that many people seem to be surprised. To understand what I mean, consider the random memory corruption error situation.
   These issues are often difficult to find, and time-consuming, so we want to use all the tools available to assist in this process. Any competent Windows Debugger tool package should be the most useful tools page heap, it is RTL heap of a special mode (which implements the api HeapAlloc and other public Win32 heap).
   Each allocated page stack at the end (or before, depending on its configuration) is placed a guard page. This protection page is marked as inaccessible, so any attempt to write to exceed the allocated memory area boundary has been assigned attempts will immediately access violation and error, rather than leaving damage in the future lead to random failures. In fact, page heap heap corruption allowing many scenes in "unarmed" capture guility party.
   Unfortunately, debug builds greatly reduces the operational capacity of the page heap. This is because when the debug version of the C run-time, any memory allocation through the CRT (eg new, malloc and soforth) before and after the distribution has a special inspection and fill patterns. These fill pattern designed to help detect memory corruption problems. When using such API, such as a free memory block returns, CRT first fill pattern is checked to ensure that they are intact. In case of discrepancies, CRT will break into the debugger and notifies the user memory is corrupt.
   If so far been tracking, it is easy to see how does this conflict with the page heap. The problem is that, from the perspective of the stack, each distribution CRT debug metadata (including inspection and filling mode) is assigned to a part of the user, thus, after filling mode (or before, if the under-run protection is enabled) is placed special protection page. This means that some memory corruption error class will cover the debug CRT metadata, but does not trigger page heap, which means that the only indication of memory corruption when released will be allocated, rather than the damage actually occurred.
   
3. In the release version, local variables and source line stepper is not reliable. Also, and as the first point, enter dependent on these convenience model is dangerous because (or in a manner intended) after the optimizer to use the program, they do not work in the distribution. If you are accustomed to always rely on local variables and source code line support, when used with a debug build, then when you have to debug release build, you will be in a state of rude awakening. At work, I have repeatedly drawn to come help some people, because they took the wrong way when debugging something, because local variables displayed in the wrong variable content distribution.
   The moral of this story is do not rely on the information provided by the debugger, because it only build reliable debugging. Even so, the local variable display also will not work unless you're stepping through source code line mode, as in the source line of code, local variables may not be in accordance with the debugger desired manner (in the single-step assembly mode) initialized (given debug information).

Now, for clarity's sake, I'm not saying anyone should be completely abandoned debug builds. Debug version adds many valuable check (assertion, VS CRT enhanced verification and iterators stack variables to check damage, to name a few). However, the ability to debug release version of the problem is very important, and in my opinion, always rely on the debug version can do this is harmful. (Obviously, this may be different, but this is only based on my personal experience.)
When I debug something, I usually use only compiles mode and line number information (if available) (for manual and instructions source code matches). Of course, in many cases (if any), the source code is still a useful time-saver, but I do not want to rely on the debugger to "properly handle" these things, because in the past, the source code is burned too many times, returns an incorrect result in non-debug build.
Just a little practice, you can get by with some basic disassembly text to read and review the stack and register contents obtained local variables display the same information. Also, if you can do this in debug builds, then by definition, you should be able to do this in the distribution, even if the restriction debugging information format, the debugger can not track a local variable is correct.