Freigeben über

F5 vs. Ctrl-F5

  • Artikel

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