Adapts to everyone's workflow
Memory Validator allows you to find otherwise hard to isolate errors, using an intuitive user interface.
Many query options are provided so that when faced with a large amount of data you can search or filter to reduce the amount of data to examine.
Want to edit the offending source code? Simple - just double click on the code fragment shown and the appropriate source code file will be loaded into Memory Validator's colour coded editor, or into Microsoft® Visual Studio®, or you can choose your preferred awesome editor.
Memory Validator can monitor regression tests, producing HTML and/or XML reports detailing regressions and improvements (compared to a baseline).
You can even reload the saved session at a later date and interact with the collected data. Being HTML or XML output, the results can be used to create reports targeted to the appropriate audience: the management team; quality assurance team; or detailed stack traces for the software engineers.
Designed with principles
Memory Validator has been created with the following principles in mind:
•must not adversely effect on the program's behaviour |
Any hooks placed into the target program's code must not affect the registers or the condition code flags of that program. The program must behave in the same way when being inspected by Memory Validator as without.
|
•must be reliable and avoid causing the target program to crash |
Since we can't know exactly which DLLs and other components are present on every computer that Memory Validator is installed on, every hook and group of hooks is configurable so that they can be enabled or disabled, and/or installed or not installed.
Thus if a new DLL is released in the future that causes problems with certain functions, you can disable the hooks for those functions, and continue using Memory Validator until a fix for the new DLL's behaviour is available.
|
•must have as little impact on the target program's performance as possible |
You can enable and disable as many or as few function hooks as you wish. For example:
If you are only interested in the CRT for a particular bug, turn all the COM, uninitialized data, buffer and handle checking off.
If you are only interested in buffer overflows turn everything off except the buffer checking hooks.
If you have handle leaks that you know come from the GDI, turn off all other handle checking code and only check the GDI handles.
If you want to go deeper than that and only check handles from GetDC() and ReleaseDC() you can do that too!
|
•must have a user interface independent of the target program |
Memory Validator's user interface is independent of the target program. So for example:
If the target program crashes, the user interface will not crash - you will still have data to work with.
If the target program is stopped in the debugger, Memory Validator's user interface will continue to work.
In the unlikely event that the Memory Validator user interface crashes, your target program will not crash.
|
•must be flexible |
We know our users like choices! Where there are multiple ways of presenting the data, the user is given a choice over how that display works, so that not all users have to work with the same settings. |
