The Breakpoints tab allows you to control how Memory Validator responds to error conditions it detects in your application, such as prompting for dropping into a debugger.

 

The picture below shows the default settings:

 

 

 

Breakpoints

 

Memory Validator can cause the target program to display warning dialogs or stop at a breakpoint when various conditions are met during the allocation or deallocation of an object.

 

 

•Display an Abort/Retry/Ignore warning dialog when errors are detected shows the warning dialog below (disabled by default)

 

 

The warning dialog message varies according to the error encountered

Abort lets the program to terminate at this point

Retry enter the debugger

Ignore lets the program to continue as normal

Don't show this again prevents seeing warning dialogs (whatever the message) for the duration of this session

 

 

•Drop into debugger when errors are detected forces a breakpoint instruction (int 3) to be executed causing the program to stop in the debugger, if attached (disabled by default)
 

If the program is not attached to a debugger, the standard Microsoft® attach to debugger dialog will be displayed.

 

If both the above options are selected, the first one will be used as it allows the user to action the breakpoint by choosing Retry.

 

•When program execution reaches ExitProcess(), drop into debugger forces a breakpoint instruction to be executed on exit, showing a dialog as below

 

 

Debug enter the debugger and determine what caused the process to exit

Continue allow the program to exit as normal

 

 

Exit without warning!

 

Some bugs manifest themselves by the process suddenly exiting without any particular reason.

 

There are two common causes of this:

 

•The program encountered a serious error, did not warn the user and called exit() or ExitProcess()
 

If the program calls exit(), the code will still be routed via ExitProcess().

 

•The program exhausted its stack space and could not continue
 

It's possible there's not even enough stack space to warn the user that the stack space has been exhausted!

 

When the program runs out of stack space, Memory Validator can't help.

 

 

 

Just-In-Time debugging and exception handling

 

If your program has an exception handler that catches exceptions and closes the application, enabling these options may cause your program to terminate instead of causing the debugger to attach to your program. Otherwise, the options described here will perform correctly.

 

For breakpoints triggered by Memory Validator to work, your debugger (Microsoft® Visual Studio® or other) must have Just-In-Time debugging enabled.

 

In older versions of Microsoft® Visual Studio®:

 

 Tools menu Options... Debug tab select the Just-in-time debugging

 

 

In newer versions of Visual Studio®:

 

 Tools menu Options and Settings... select Debugging in the list Just-in-time tick the relevant checkbox(es)

 

 

 

'Stop When' conditions

 

An ID, an address or a size can be checked at various times to cause either a warning or breakpoint, as designated in the breakpoints settings:

 

•Stop When Delete Request With ID enter an ID to be used for the delete request to trigger the warning dialog

 

This is similar to using the Microsoft® _crtBreakAlloc variable in the debugger. See also _CrtSetBreakAlloc().

 

•Stop When Delete Address enter a specific address for deletion to trigger the warning dialog

 

•Stop On Allocation Greater Than enter a size theshold above which allocation will trigger the warning dialog

 

All three conditions can be active at the same time, and leaving any of the above fields blank resets that condition.

 

 

Reset All - Resets all global settings, not just those on the current page.

 

 

Reset - Resets the settings on the current page.