The Hook Safety page allows you to specify which safety features are enabled during hooking.

 

 

 

Hook safety with Release Mode software

 

When hooking functions, it is important that the information being used is verified against the actual object code being modified to insert the hooks.

 

This is especially important in Release builds where the code optimizer may have rearranged the object code so that it does not match the information in the PDB and MAP files.

 

To ensure this, the default behaviour is to disassemble each function and check it prior to hooking it. If the function can't be disassembled, it won't get hooked.

 

You can switch off disassembling of functions and hook them anyway:

 

•Don't hook functions if function cannot be disassembled uncheck to hook the functions anyway

 

It's recommended to keep this option enabled for Release builds

 

 

Hook safety with multi-threaded applications

 

When working with multi-threaded applications, it is possible for the thread hooking the application to be modifying code that is executing in a different thread.

 

If you think this might be affecting you, you can pause the other threads while hooking..

 

•Pause other threads whilst hooking check to pause other threads

 

 

Hook caching

 

When hook caching is enabled, the first time a module (DLL or EXE) is instrumented, various information about the module is stored in a cache file.

 

Every subsequent time the module is instrumented, the cached data is used to instrument the module, rather than inspecting the module again.

 

This can provide quite significant performance improvements.

 

•Cache instrumentation data check to use the instrumentation cache

 

If the module is recompiled/relinked, the cache data will be discarded and recalculated.

 

 

Cache invalidation

 

The data in the instrumentation cache for each DLL is invalidated and discarded when:

 

•The module is recompiled or relinked

 

•Hook Control settings are changed

 

•Hook Safety settings are changed

 

 

About cache files

 

Cached instrumentation files are stored in the same directory as the module to which they refer.

 

They have the same name as the module, with the .svlPV_performance extension.

 

For example, instrumentation data for:

 

 c:\winnt\system32\msvcrtd.dll

 

is stored as:

 

 c:\winnt\system32\msvcrtd.dll.svlPV_performance

 

 

Cleaning up the cache files

 

You may not want to keep cache files lying around on your system amongst your code, so Performance Validator provides a utility to automatically clean up those files.

 

Files with the .svlPV_performance extension are searched for on your drive, and deleted if found.

 

•Clean instrumentation cache shows the Symbol Cache Cleaner utility dialog

 

 

 

•Include network drives tick this to clean up networked drives

 

•Scan and delete symbol cache files starts the scan

 

 The dialog shows a count of the number of files scanned and the total number of cache files found

 

•Close cancels the process and closes the dialog

 

You can continue to use Performance Validator as normal while the scan takes place. If starting a new session that caches instrumentation, be aware that cache files may be recreated after the scan has passed!

 

 

Cached files and the Class and Function Filters

 

If the Class and Function Filter has been set up to only include or exclude specified classes or functions, then the Cached Instrumentation data will be ignored.

 

Instead, functions will be hooked according to the Class and Function Filter.

 

 

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

 

 

Reset - Resets the settings on the current page.