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)
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
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.
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.
Freddy and Reoa have the correct solutions. But I wanted to add a reason why not to use a MessageBox.
Displaying a MessageBox only partially stops your application. Because you are showing UI, a message pump is still running on at least one thread in your program. So if your code does any of the following.
- Communicates via Windows Messages
- Has non-trivial UI
- Is Multi-threaded
You will essentially be requesting a debugger in one state but attaching to your program in a completely different state. This can lead to bewildering situations and bugs.
We recently made a change in our code base to never show a MessageBox in order to facilitate break for this very reason. It produces very bad behavior for a non-trivial application.
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.
Look up:
DebugBreak , __debugbreak and friends
or
static void timeToChase() { __asm { int 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.
