Take the 2-minute tour ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.

I have create a macro,

#define DEBUG_BREAK(a) if (a) __asm int 3;

But the problem is if there is not a debugger attached, the program would run incorrectly.

So I need to know whether there is a debugger attached. If it is, the app should call int 3. Otherwise, it should not.

How could i do this?

share|improve this question
    
poosible duplicate of stackoverflow.com/questions/4818628/… –  ZoomIn May 22 '13 at 8:40

3 Answers 3

up vote 2 down vote accepted

You can use CheckRemoteDebuggerPresent or IsDebuggerPresent - and no, CheckRemoteDebuggerPresent doesn't necessarily mean that the debugger runs on a different machine, just that there is a debugging process in the system that can deal with breakpoints etc (when using a Remote Debugger, there is a small process on the target system too, which is where it comes from).

Edit: And at this point I would DEFINITELY suggest some form of function, rather than a macro.

share|improve this answer
    
You beat me to it :) +1 –  Ahmed Masud May 22 '13 at 8:41
1  
If I use function, the debugger would interrupted in the function, which is not what i want. –  Jichao May 22 '13 at 9:05
    
Why? The only thing the function will do is return to the call site ... –  Useless May 22 '13 at 9:29
    
@Useless: I need to break at where i input DEBUG_BREAK, otherwise I would rather use the breakpoint in the visual studio. –  Jichao May 22 '13 at 12:34
1  
@MatsPetersson: Yes shift+f11 could send me to the caller of DEBUG_BREAK, but if i use macro, the program would stop at right the caller rather that the inner of the function. –  Jichao May 22 '13 at 12:45

For what you want to do, it would be better if you'd use the proper exposed kernel32.dll function DebugBreak. Basically along the lines of

#define DEBUG_BREAK(a) if(a) if (IsDebuggerPresent()) DebugBreak()

or instead of doing the __asm int 3 routine, use the VC-supplied intrinsic __debugbreak, i.e.:

#define DEBUG_BREAK(a) if(a) if (IsDebuggerPresent()) __debugbreak()

The latter makes a difference (compared to int 3) when compiling with /clr as pointed out in the documentation. Of course the intrinsic hasn't always been there, so depends on your VS/VC version (which you don't state).

In both cases you need at least windows.h included for IsDebuggerPresent().


However, that's the exact reason you would have a debug and release build and build those conditionally. Keep in mind that the optimizer can garble the results in the debugger despite your efforts to carefully place the breakpoints in code. The reason is simply that some lines in your source code won't be represented anymore or will have changed in a deterministic manner. So using one configuration for both doesn't make a lot of sense. So what I'm saying is to use something along the lines of:

#ifdef _DEBUG
#   define DEBUG_BREAK(a) if(a) __debugbreak()
#else
#   define DEBUG_BREAK(a) do {} while(0)
#endif
share|improve this answer

You might take a look on my latest post about detecting a debugger, here:

http://blog.szulak.net/programming/basic-debugger-detection-techniques-in-windows/

share|improve this answer
    
would be great if you would quote relevant parts at least. If the link goes stale in a few months or years your answer will be meaningless otherwise. –  0xC0000022L Aug 21 '13 at 11:45
1  
Provide some explanations rather than links... Helps a lot... –  NREZ Aug 21 '13 at 12:06

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.