Please enable JavaScript to view this site.

Memory Validator Help

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-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 instructionStep shows the warning dialog below (disabled by default)

 

warning-dialog-settings

 

The warning dialog message varies according to the error encountered

Abort instructionStep lets the program to terminate at this point

Retry instructionStep enter the debugger

Ignore instructionStep lets the program to continue as normal

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

 

 

Drop into debugger when errors are detected instructionStep 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 instructionStep forces a breakpoint instruction to be executed on exit, showing a dialog as below

 

exit-process-dialog
 

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

Continue instructionStep 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 instructionStep Options... instructionStep Debug tab instructionStep select the Just-in-time debugging

 

JustInTimeDebugging

 

In newer versions of Visual Studio®:

 

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

 

just-in-time-debugging-settings

 

 

'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 instructionStep enter an ID to be used for the delete request to trigger the warning dialog

 

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

 

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

 

Stop On Allocation Greater Than instructionStep 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.