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

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

1) what version of CreateProcess do you call?

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

. 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

Here’s a matrix:

  F5 (under debugger) Ctrl+F5 (outside debugger)
Managed-only ICorDebug::CreateProcess,

0 flags

0 flags
Native-only kernel32!kernel32!CreateProcess, 


0 flags
Interop (aka Mixed-mode) ICorDebug::CreateProcess,


0 flags


Comments (5)

  1. Luke says:

    When in debugger it launches my program under some vshot.blah.exe. What a crap is that?

  2. jmstall says:

    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.

  3. 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.

  4. jmstall says:

    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.

  5. jeff anderson says:


    Thanks, I’m already have bug report on the VS2005 site regarding this:


    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