Memory Validator has many settings that control the collection and display of the data.

It is possible either the default settings or settings from a previous session are set to ignore the data you want collected.

For example, let's say you ran a session and turned off all the handle collecting functions in the Handle Allocation Hooks tab on the global settings dialog. Even with the hooks inserted into your target program the hooks would be disabled, and no information on handles would get displayed.

Here's some possible reasons for your data not being collected:

•Program starting too quickly

 
Starting your program in Normal or Idle modes may mean part of the code in which you want to track allocations may get executed before Memory Validator has attached to the program.

 
If this is happening use the Paused or Suspend modes to start the program.

•Data collection is switched off

 
Check that the green data collect icon is not displayed on the session toolbar (it will be disabled if data is being collected).

Read further information on data collection.

•Data collection hook groups not installed

 
The appropriate hook group for the data you wish to view may not have been installed in the target program when the target program was attached to.

The hook groups installed are configured from the Collect tab on the global settings dialog.

Enable the hook group and re-run your session.

•The individual hooks for the function you are interested in may have been disabled

 
Check the hooks using the Memory Allocation Hooks, Handle Allocation Hooks, Buffer Manipulation Hooks tab on the global settings dialog.

If the data hooks were installed, then the hooks will start collecting data once you enable the data hooks.

•Data is being collected but not displayed

 
Check that the controls for the view you are using are set so that the appropriate data will be displayed.

Some of the views have the data display controls as part of the view. The Memory tab has its control on the memory display settings dialog.

Other checks

Check that there are no filters (in Global, Session and Local filter groups) that could be suppressing the display of the data.

Check that the thread filter is not suppressing the display of the data.

Statically linked to C runtime libraries?

If your program is linked statically to the C runtime libraries, please read the before you start information.

A common reason for not seeing expected data is that the required hooks have been disabled.

Here's a few things to check for:

•the correct hooks to monitor the memory, handle and/or COM allocations are installed

See the Collect tab of the global settings dialog.

•the relevant hooks are enabled

See the Hooks tab of the global settings dialog.

•the collected data is displayed - it might be being collected, but not displayed

See the memory tab display settings dialog.

• global and session filters are not filtering the data from being displayed

•local filters (for the view being used) are not filtering the data from display

•the target program really is executing the code you think it is executing

If you are not seeing allocations for the C runtime heap, but you are seeing allocations for all other heaps and for handles, check to see if you are linked to the statically linked C runtime libraries.

If your program is linked statically to the C runtime libraries, please read the before you start information.

See also: Memory Validator isn't collecting any data, why? (above)

The functions LoadIcon(), LoadCursor() and LoadCursorFromFile() create shared Icons and cursors.

These objects are shared between multiple applications.

Since they can't be leaked, Memory Validator doesn't track them.

This also means that when your application has finished with them, they don't need to be destroyed.

We provide hooks for all the functions that we think are required to be hooked in order to give you the best tool we can to aid you in your software development tasks.

Inevitably, new APIs with new functions get released, and we continually update Memory Validator to reflect this.

However, if we missed an API or method which is important for a bug you're working on, please drop us a line!

If we think the API should be added to Memory Validator list of hooks, we'll make it happen and let you know either way.

Sometimes in release mode programs, callstacks of a useable length cannot be collected.

One reason for this is that high levels of compiler optimization have removed the stack frame instructions (push EBP prologue and POP EBP epilogue) and have not included adequate frame pointer omission data (FPO_DATA) in the PE file for the functions that have been optimized.

It can also happen in debug mode programs, that if extra data is placed on the stack during custom assembly calls or hooks, the DbgHelp StackWalk() function may fail to find the next EBP stack frame, halting the stack walk.

Memory Validator has advanced stack walking options that can walk callstacks even when DbgHelp StackWalk() can't.

When using the find memory dialog or the find object type dialogs you might occasionally see datatypes listed that don't produce any search results.

This is usually because the datatypes have been loaded from the file type cache.

To remove the cached datatypes you need to flush the datatype cache.

Some double delete callstacks do not show the allocation location.

A few possible causes for this might be as follows:

•Memory Validator was not collecting data when the memory was allocated

This could be because the memory was allocated before Memory Validator was attached to the process, or because data collection was turned off when the memory was allocated.

•Information about the memory allocation has been discarded

This can happen if the Discard stack traces for freed memory check box is selected on the Allocation History page of the global settings dialog box.

•The double delete is being recognized as an invalid memory location

Consider the following:

   char   *ptr;
   ptr = new char [3000];
   
   // .. do some work
 
   ptr = ptr + 10;   // pointer no longer points at the start of the memory block
   delete [] ptr;    // incorrect
 
   // .. do some work
   
   delete [] ptr;    // incorrect double delete

Not only is the first delete incorrect because of the altered pointer value, but there is a second delete with the same (incorrect) pointer value.

When Memory Validator looks for the associated allocation location, it will never find it because there are no allocations at the address "ptr + 10".

In this way, the double delete can be detected, but the allocation location can't be detected.

If you have used the Ordinal Handling utility, you may still find the ordinal names have not been converted in symbol names,

Here's a couple of reasons:

•You may not have enabled ordinal handling

Use the Source Parsing page on the global settings dialog to set the Map Ordinals to function names option

•You haven't defined the ordinal to symbol conversion for the correct DLL in which the ordinals are defined

Double check the DLL for which you defined the conversions really include those ordinals.

 
See the topic on Ordinal Handling

There are a couple of resons why the collected callstack may be shorter than you specified:

•The complete callstack may simply have less entries than the specified depth

•Some of the items in the callstack may have been omitted to provide a more useful stack trace

The second option sounds counter-intuitive, but here's an example - tracking a call to operator new.

For Debug builds operator new calls to malloc_dbg(), so the callstack will be something like (various functions omitted for clarity):

   malloc_dbg()
   operator new()
   myFunctionThatCallsNew()
   functionBlues()
   functionJazz()

The callstack seen in this case would be:

   myFunctionThatCallsNew()
   functionBlues()
   functionJazz()

Examining the source code to myFunctionThatCallsNew() would show the call to operator new().

This is done so that program calls to operator new() are not confused with program calls to malloc() or malloc_dbg().

In this example 2 items are removed from the callstack, but since only the specified depth of callstack was actually collected, it ends up shorter.

Memory Validator does try to correct for this by estimating the number of items that might be excluded before collecting the trace, but occasionally you'll still get a shorter trace than expected.

If you need longer callstacks collected for a particular bug you are investigating change the data collection callstack monitoring settings to collect more of the callstack, or even the complete callstack.