Adapts to everyone's workflow
Thread Validator allows you to find otherwise hard to isolate errors using an intuitive colour-coded user interface.
Data can be collected using a variety of different query methods. When faced with a large amount of data you can search or filter the data.
If you want to see the source code that caused a deadlock, just double click on the display entry to view source code in the adjacent window.
Alternatively, to edit the code, double click on a code fragment shown and the appropriate source code file will be loaded into Thread Validator's colour-coded editor, or into Microsoft® Visual Studio®, or you can choose your preferred awesome editor.
You can save sessions, reload them at a later date and still interact with the analysis data.
You can also export session data to HTML or XML which can be used to create reports targeted to the appropriate audience: the management team; quality assurance team; or to create detailed stack trace reports for the software engineers.
Designed with principles
Thread Validator and the other products in our suite of tools have been created with the following principles in mind:
•must not adversely effect 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 Thread 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 Thread Validator is installed on, every hook 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 Thread 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 |
Thread Validator has very little effect on the target applications performance, but you can also enable and disable as many or as few threading hooks as you wish.
For example:
If you're only interested in monitoring performance of a particular area of code, you can pick only that directory to be hooked.
|
•must have a user interface independent of the target program |
Thread Validator's user interface is independent of the target program.
This means:
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, Thread Validator's user interface will continue to work.
In the unlikely event that the Thread Validator's own 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. |
