F5 vs. Ctrl-F5

In VS, F5 will launch your application under the debugger. Under the
debugger, you'll hit breakpoints, be able to edit-and-continue, and do all the
debugger things you know and love.

Ctrl+F5 will launch your application outside of the debugger. This is like
launching your app from the "start | run" menu, except VS becomes the parent
process instead of explorer. Ctrl+F5 is purely convenience functionality.

Ideally ,
running under a debugger shouldn't change the app's behavior. An app may do
something evil, like

detect if a debugger is attached to itself, and use that to do different
behavior.

Under the covers, they both translate to calls to CreateProcess. The
questions are:

1) what version of CreateProcess do you call?

kernel32!CreateProcess is the OS API to create a process. ICorDebug::CreateProcess
has the same signature as kernel32's, but the ICorDebug version will launch the
program as a managed debuggee.

2) what flags do you pass? CreateProcess takes a set of

flags. If you pass (DEBUG_PROCESS | DEBUG_ONLY_THIS_PROCESS) to the flags,
then the child process will be a native.

If you enable both managed + native debugging, then you've enabled
interop-debugging.

Here's a matrix:

	F5 (under debugger)	Ctrl+F5 (outside debugger)
Managed-only	ICorDebug::CreateProcess, 0 flags	kernel32!CreateProcess, 0 flags
Native-only	kernel32!kernel32!CreateProcess,  DEBUG_PROCESS | DEBUG_ONLY_THIS_PROCESS	kernel32!CreateProcess, 0 flags
Interop (aka Mixed-mode)	ICorDebug::CreateProcess, DEBUG_PROCESS | DEBUG_ONLY_THIS_PROCESS	kernel32!CreateProcess, 0 flags

Comments

• Anonymous
  September 28, 2005
  The comment has been removed
• Anonymous
  September 28, 2005
  I forgot to mention that.
  VS 2005 tries to front-load debugging startup time by pre-creating the debuggee and then attaching to that. The precreated-debuggee is "VsHost", and it then loads your real debuggee.
  See http://blogs.msdn.com/dtemp/archive/2004/08/17/215764.aspx for more details.
  
• Anonymous
  October 16, 2005
  The mixed mode debugger does changed the app's behaviour - at least that's my experience with /clr. I've noticed very slow performance of /clr compiled code under the managed debugger in VC 05 RC. In particular, calls to standard library functions. For example write a loop to create a million random numbers with rand() (compile with /clr) and run under the managed debugger; it's about 100 times slower then running without the debugger!
  
  That said, /clr:pure seems to be OK in the same scenario.
• Anonymous
  October 17, 2005
  I'm disappointed about the slowdown. I'll need to look at that closer.
  Debugging will always have some perf impact; but the numbers you point out here are signifcantly larger than ideal.
  
• Anonymous
  October 17, 2005
  Mike,
  
  Thanks, I'm already have bug report on the VS2005 site regarding this:
  
  http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackId=e976ea2a-ba1e-4537-9493-46af9429a81e
  
  There is a simple test case posted there. I hope I'm wrong or this has been fixed in the RTM as I'm currently unable to debug a mixed mode C++ app (without a lot of pain) that I'm porting from VS 03.
  
  jeff anderson
  Braid Media Arts
  kilroytrout@hotmail.com