The Collect tab allows you to specify which groups of hooks are installed in the target program when a session starts.
The following image shows all the default options:
Hooks specified here will be overridden by inclusion in the process modules list of the Hooked DLLs settings.
Each of the Memory, Handles and Other checkboxes includes or excludes the relevant hooks for tracking the following items
•C / C++ install hooks for C runtime heap
•Delphi Delphi runtime heap
•Fortran 95 Fortran runtime heap
•Open GL Open GL handles
•Heap Memory install hooks for HeapAlloc, HeapRealloc, HeapFree functions
•Local Memory LocalAlloc, LocalReAlloc, LocalFree functions
•Global Memory GlobalAlloc, GlobalReAlloc, GlobalFree functions
•Virtual Memory VirtualAlloc, VirtualFree, VirtualAllocEx, VirtualFreeEx groups of allocation functions
•CoTaskMemAlloc CoTaskMemAlloc group of allocation functions
The preferred way of allocating memory in COM objects.
•SysAllocString SysAllocString group of allocation functions
Allocates, reallocates and deallocates BSTR objects (OLE Strings).
•DCOM an additional group of SysAllocString hooks are inserted for use in DCOM transactions
Only available when SysAllocString is selected above, and not required for most applications.
•Misc. Allocations miscellaneous allocation functions
•IMalloc IMalloc functions
The old way of allocating memory in COM objects, prior to the introduction of CoTaskMemAlloc.
See also, notes about IMallocSpy below.
•NetApi Memory NetApi allocation functions
•Marmalade Marmalade game SDK allocation functions
s3eMalloc, s3eRealloc, s3eFree, s3eBaseMalloc, s3eBaseRealloc, s3eBaseFree
•Custom Hooks hooks for allocation functions tracking custom memory
Default settings are with all memory hooks selected, except for lMalloc.
For more information about working with Marmalade read Working with Marmalade game SDK.
We do not recommend using the IMallocSpy option.
We have noticed that some functions (SysAllocString) cause many allocations to be reported by IMallocSpy, and yet the equivalent deallocation function SysFreeString does not cause the same allocations to be reported as deallocated by the IMallocSpy interface. This results in Memory Validator displaying misleading information. We recommend that the memory hooks for CoTaskMemAlloc, SysAllocString and Misc Allocations are used rather than IMallocSpy.
•Kernel install hooks for handles allocated in Kernel32.dll
•Advapi handles allocated in Advapi32.dll
•GDI handles allocated in gdi32.dll
•User handles allocated in user32.dll
•Shell handles allocated in shell32.dll
•Common Control handles allocated in comctl32.dll
•Winspool printer spool handles
•Winsock socket handles
•WinHttp http handles
Default settings are with all handle hooks selected.
•COM Reference Counting install hooks for tracking COM object creation and reference count tracking.
See section below regarding possible erratic behaviour when using COM reference counting hooks.
•Trace Messages tracking TRACE() messages and OutputDebugString()
•Delay loaded function hooking functions which are delay loaded will be hooked as the functions are resolved by the delay loading process
Not all DLLs are delay loaded, but typical examples are COMCTL32.DLL and some COM libraries.
If this option is not selected then any functions that would normally be hooked, but which have been delay loaded, will end up not being hooked.
•Hook functions via GetProcAddress() calls that are made to functions via a pointer obtained from GetProcAddress() will be hooked.
•User Defined Memory calls to the Memory Validator API to track user defined calls will be allowed to send data to the user interface
Default settings are with only Delay loaded function hooking enabled.
If a function that is looked up via GetProcAddress() is also a function that would normally be hooked via Import Address Tables, turning this option on will mean that that function will be hooked even if it is called via pointer returned from GetProcAddress(). This is typical source of unreported leaks in many memory leak detection tools, they don't detect calls via pointers from GetProcAddress().
Selecting COM Reference Counting can cause erratic program behaviour if a hook gets inserted incorrectly.
This is because the COM hooks alter the machine code of the program and can get confused by the program structure. This is not typical of user written COM objects, but is typical of Microsoft® COM objects which appear to share entry and/or exit points between common functions.
Random crashes: If a program crashes randomly at start up, or seems to get stuck in an infinite loop (cpu at 99%) try disabling COM Reference Counting and check to see if the program behaves normally.
Reset All - Resets all global settings, not just those on the current page.
Reset - Resets the settings on the current page.