• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 326
  • Last Modified:

User breakpoint called from code at 0x77F76148

I recently got this message from VC++ 5.0 (w/ VS97 SP3)
running on NT4.0 (w/ SP3).

"User breakpoint called from code at 0x77F76148"

The disassembly showed "int 3" (interrupt 03h)

I think this means that the program told the CPU to
stop at a breakpoint.  I think this is cool!  Is there
a sanctioned way to code this in my programs?  I'd like
to tell the program to stop at a certian point and let me
step from there without setting the breakpoint in the IDE.
0
alfredj
Asked:
alfredj
  • 4
  • 2
1 Solution
 
nietodCommented:
just use the statement

_asm int 3

to place a "hard" breakpoint.
0
 
nietodCommented:
a couple of tips.  I use a preprocessor macro like

#if DEBUG
#define int3 _asm int 3
#else
#define int3
#endif

to remove the interrupts from release code.  Also I define a macro used to throwing exceptions that always does an int 3 before throwing.  That is very hand because once the exception is thrown and later caught, it is hard to backtrack and figure out what went wrong.

Let me know if you have questions.
0
 
alfredjAuthor Commented:
_asm int 3.  Okay.  That much I knew, but I was hoping for more
"expertise" in the "exchange".  I'll up the points if you want, but could you explain more (If there is indeed more to explain?)

Is there anything good/bad/to-watch-out-for when using int 3?

0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
alfredjAuthor Commented:
Thanks!  I thought that your short answer was all you
were going to say, but I guess you just put that in there
so you could be first.

Thanks again!


0
 
nietodCommented:
I'm sorry, I'm not sure what more you want.  (I can't image what more there is).

There is no problem in using it.  I do it all the time.  The only annoyance is that the debugger displays a message box when it encounters it.  You  have to clear the message box before you can continue debugging/executing.  This of course doesn't happen with regular breakpoints.  (This happens because the debugger is "surprised" to find the int 3 as it didn't put it there.  With regular breakpoints, it expects to be called when the breakpoint is reached.  The hard ones are a surprise.)

What more are you looking for?  
0
 
nietodCommented:
Okay.  well let me know if there's more you need.  
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now