Start Debugging vs. Start Without Debugging

Keyboard:  F5; CTRL + F5
Menu:  Debug -> Start Debugging; Debug -> Start Without Debugging
Command:  Debug.Start; Debug.StartWithoutDebugging
Versions:  2008,2010
Published:  11/1/2010
Code:  vstipDebug0037

 

While researching this one I came across a LOT of misinformation concerning what is actually happening here.  There seems to be a great deal of confusion as to what is actually happening when you use Start Debugging (F5) versus Start Without Debugging (CTRL + F5):

 

 

 

Starting With Debugging

Let's start with the basics:  When you press F5 (Start Debugging) in Visual Studio it launches your application, attaches the Debugger, and let's you do all the "normal" things you would expect: 

 

According to the documentation (https://msdn.microsoft.com/en-us/library/k0k771bt(v=VS.100).aspx) here is what the Debugger does:

"The Visual Studio debugger is a powerful tool that allows you to observe the run-time behavior of your program and locate logic errors. The debugger works with all Visual Studio programming languages and their associated libraries. With the debugger, you can break, or suspend, execution of your program to examine your code, evaluate and edit variables in your program, view registers, see the instructions created from your source code, and view the memory space used by your application."

 

The Debugger:   Release Builds

One popular misconception is the Debugger doesn't come into play for Release builds.  This isn't true.  Set a Breakpoint in some code for a Release build and then press F5 to see if is stops there:

 

 

Of course it does!  The Debugger is attached!  That is what is happening.  Now, there are some things that aren't happening as well.  For example, you can't use the System.Diagnostics.Debug class methods to send messages to the Output window since the compiler strips them out for Release builds:

 

 

 

Start Without Debugging

This is exactly what it sounds like.  It starts the application WITHOUT THE DEBUGGER ATTACHED.  That's it!  Nothing else.  It just doesn't attach the Debugger.  Otherwise everything else is the same.  So, the practical implications of this are obvious:  Without the Debugger attached when the application runs it will not hit Breakpoints, emit Debug messages, etc.  So now let's deal with the biggest myth about Start Without Debugging.

 

Myth: Start Without Debugging Creates a Release Build

Nope.  It uses the build you are currently on.  So if you are using a Debug build and you press CTRL + F5 then it will run that Debug build.  The easiest way to test this is to use conditional compilation to see if you are using a Debug build:

 

In this example, the Console statement will run but the Debug statement will NOT run because the Debugger is not attached.  So I will get this output:

 

And, if I attach the debugger after pressing CTRL + F5, to this process:

 

Then this is what I get:

 

The Debug messages haven't been stripped out because I'm using a Debug build of the application.

 

 

 

Finally

Okay, so the obvious question is "Why?".  I mean, why would they give us this option?  Well the most obvious answer is so we can run the application without having to hassle with disabling breakpoints, etc. to do a quick "Smoke Test" and see if it runs.  There may be other reasons you have for wanting to run without the Debugger attached as well.  So now you have a better idea of the difference between Start With and Start Without Debugging.  Go forth and debug away!

Comments

• Anonymous
  October 31, 2010
  Is there a difference in the "Edit and Continue" experience. AFAIK with debugging you can edit your code and continue with the modified code. without debugging and attaching the process later does not have this feature.

• Anonymous
  October 31, 2010
  There's one significant difference for C++ code. Start without debugging and your program won't use the Windows debug heap, but start with the debugger attached and it will. This means there can be bugs that only show up when you start without debugging. The trick to debugging them is to start without debugging, and then attach to the process before it crashes.

• Anonymous
  November 01, 2010
  Nice tip, thanks for sharing! Knowing debugging shortcuts help you very much with fast and efficient debugging. Also, you can use System.Diagnostics.Debugger to set breaks programmatically.

• Anonymous
  November 01, 2010
  @Ewald -- Not sure if the "Edit and Continue" experience is impacted.  I'm working on a post on this feature so will test then and see how it is impacted.

• Anonymous
  November 01, 2010
  One more reason to start without debugger: Everytime you load a new module, the debugger looks for the PDB, loads it, etc. This obviously slows down the start of a large application quite a bit. If you have a lot of modules which are only used on demand (say during startup) and then unloaded again, a lot of time might be wasted loading the debug info which isn't used anyway.

• Anonymous
  January 02, 2011
  It is also useful to run without debugging if you want to use the JavaScript debugger in a web browser rather than using the Visual Studio debugger for debugging JavaScript.

• Anonymous
  March 21, 2014
  Thanks for sharing. The reply by Adam helps me a lot to fix bugs occurs only when start without debugging.

• Anonymous
  May 17, 2015
  ya, in simple words even you set up some break point,  control-F5 won't hit them debugging, breakpoint, watch values are so confusing,  is there any MODEL ANSWER mode , so we know where we got it wrong !! (easier for everyone)