Bug Validator allows you to record the execution history of an application and to decode the execution history logs recorded at customer sites using Bug Validator. When you are trying to analyse "customer only" bugs or bugs that crash without throwing exceptions or dropping into the debugger, Bug Validator is a valuable tool.
Sessions can be saved and reloaded in Bug Validator for later analysis. Sessions saved using Bug Validator can be loaded and decoded so that the cause of a crash at a customer site can be analysed. Sessions can be exported to HTML or XML for providing reports that are appropriate for the management team, quality assurance team, software engineering teams.
Bug Validator has been created with the following criteria in mind.
1) Bug Validator must have no adverse effect on the program's behaviour.
Any hooks Bug Validator places into the target program's code must not affect the registers or the condition code flags of the program. The program must behave in the same way when being inspected by Bug Validator as when the program is running without being inspected by Bug Validator.
2) Bug Validator 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 Bug Validator is installed on, we have configured every hook, so that they can be enabled or disabled, and/or installed or not installed.
3) Bug Validator must be capable of having as little impact on the target programs performance as possible.
To do this we allow you to enable and disable as many or as few function hooks as you wish.
4) Bug Validator's user interface must be independent of the target program.
Bug Validator's user interface is independent of the target program.
•If the Bug Validator user interface crashes, your target program will not crash.
•If the target program crashes the Bug Validator user interface will not crash - you will still have data to work with.
•If the target program is stopped in the debugger, Bug Validator's user interface will continue to work.
5) Flexibility
Where there are multiple ways of presenting the data, the user should be given a choice over how that display works. Not all users like the same choices, so providing some choice over the display is always better than forcing all users to use the same settings.