What is the best way to attach a debugger to a pro

Question

When debugging, sometimes you need to attach an already running process instead of just starting the application in a debugger.

It's common for myself to put in a Sleep() or MessageBox call, so that it's easier to attach a debugger. I worry that some of these may be committed eventually to source control.

What is the best thing to do to avoid this situation while still delaying enough time so that you can attach your debugger to a running process?

Guarding the Sleep or message box with an #ifdef _DEBUG is one way, but I'm wondering if there is a better way.

With a Sleep you also have the problem that you may not attach in time. With a MessageBox you have the problem that you may be remotely debugging, or debugging a process that has no visible GUI (example running as a service on Vista)

Answer 1

you can use DebugBreak, check these links:

http://www.epsilon-delta.net/articles/vc6_debug.html#breaking-with-debugbreak

http://blogs.msdn.com/calvin_hsia/archive/2006/08/25/724572.aspx

Answer 2

another variant, which I sometimes use is

while( !::IsDebuggerPresent() )
    ::Sleep( 100 ); // to avoid 100% CPU load

it should just silently wait until you attach your debugger to the process.

Answer 3

__asm int 3 

This hard breakpoint will bring up the debug dialog, which will let you attach to the process. Wrap that in #ifdef _DEBUG and you'll only hit it in debug builds.

Answer 4

To attach a debugger at a particular point, you have several options:

The simplest is just to call DebugBreak, which is pretty much equivalent to __asm int 3, but also works on other architectures (MSVC for x64 doesn't allow inline assembly, if I recall correctly). This'll bring up the just-in-time debugger window, and you'll be able to select from registered debuggers (i.e. Visual Studio) to attach to the process.

Alternatively, you can introduce a call to Sleep, giving you an opportunity to attach the debugger. You should use #ifdef _DEBUG around this, to ensure that you don't actually ship with this code included.

One question: why can't you run the code from the IDE? Is it a service or an IIS-loaded DLL or similar?

In this case, you can check out the ImageFileExecutionOptions registry key, which allows you to attach a debugger at the moment that the process starts.

If you use cdb for this, you can configure it as either server or client to a WinDbg instance, and debug that way. I've done this in the past by using WinDbg as a kernel debugger, and by using ImageFileExecutionOptions to start ntsd -d with the named process. This causes WinDbg to break into user mode. This is sometimes a useful technique.

Answer 5

Look up:

DebugBreak , __debugbreak and friends

or

static void timeToChase() { __asm { int 3; }; }

Answer 6

Having to attach at 'just the right point' is a pain ... one option is to but explicit DebugBreak() statements into the code to force the issue, and guarding them with #ifdef _DEBUG would be a good idea. We use an ASSERT macro that can call DebugBreak(), so you can just write ASSERT(false)

Another option to consider is using 'image file execution options' to launch the debugger automatically. See this blog and the MSDN documentation.