Why should I start debug builds without debugging?

Question

Is there any use in running a debug build without debugging (as opposed to building a release without debugging)? And what am I missing when debugging a release assembly (as opposed to debugging a debug build)?

Answer 1

To add an answer to Adrians as a generic point, talking about building debugging and release:

Here are some factors that affect your builds:

• You are linking to a debugging or version of runtime libs (/ MD vs. / MDD)
• NDEBUG (release mode) or _DEBUG (debug mode) #defined
• _SECURE_SCL (or some equivalent) is defined (or not)
• Compiler optimization enabled (to some extent)

The "debug build" usually contains _DEBUG , _SECURE_SCL=1 , /MDd and all compiler optimizers are disabled. This leads to the “safe”, “most tested” runtime, but should also be the slowest version you can get for your executable. Speed ​​and security factors should be completely independent of whether you run your program under the debugger or not! - The debug build gives you maximum security and access to errors, completely independent of whether the program is connected to the debugger.

Next is the non-optimized version of the assembly: that is, you have all the settings for the release mode (NDEBUG, _SECURE_SCL = 0, etc.), but you disable all compiler optimizations. This is good for testing, as the performance will not be too bogged down, and you can debug it completely. Again, the usefulness of this does not depend on whether you run your program under the debugger.

Finally, full optimization will come. ( /Ox + full insertion + whole prg optimization is possible): although this is what you would like to send for performance reasons, most likely you do not have enough people in your company who are actually able to debug this. That is, given the crash dump, someone most likely needs some knowledge of asm and what the compiler outputs in order to understand the meaning of the crash dump (or even some random breakpoint when actually running under the debugger). Again, the pros / cons for a complete selection are independent of prg start / run under the debugger.

Answer 2

The biggest benefits of debugging collections (outside the IDE):

• Assertions are allowed, as well as other diagnostic code that you could compile in debug-dependent sections.
• Stack traces and variable clocks work fine, so you can ask beta testers to send you an emergency dump and debug this in your IDE later.

The biggest disadvantages:

• Slower execution, higher memory consumption, larger file size.
• Some errors are not obvious unless you compile everything with full optimization. This is because memory allocation works differently in release builds.

Many companies distribute debug builds to alpha and beta testers and switch to release builds later.

Answer 3

Running a debug assembly without debugging can give you, for example, the following advantage: if the indexer is indexed with an invalid index, you will receive an error message, in the release mode you will get undefined behavior. This is a thought. What you missed when debugging in release mode is the lack of correspondence between the source lines and the assembly code, since the optimizer is running. So much harder to debug in release mode

Answer 4

I suggest a recent experience that I cannot explain - sometimes, when I run my application, I get unhandled exceptions when working in the IDE. The problem is that I know that my exception is being processed, and I also know that I am not breaking the thrown exceptions (via CTRL-D, E). If I hit F5 several times, my error handler will eventually catch the exception and handle it properly.

The reason for this eluded me for several weeks, so when I don't want the execution to be interrupted, I start outside the IDE and just join the process later if I need to.

If you really need to see Debug output while working outside the IDE, and you are not using something like log4net to capture everything, you can use DebugView instead.