The Page Heap test uses guard pages to detect memory corruption issues in the heap. To gain the most useful information from this test, the computer should contain at least 256MB of RAM and have a 1GB page file.

There are several properties for the Heaps check that can be altered:

• Full � Check to implement full page heap. If unselect it�s normal page heap
  
  
• Dlls - Page heap allocations for target dlls only. Name of the binaries with extension (dll or something else). If you wish to enter in more than one, enter a space between the dll names.
  
  
• Size - Page heap allocations for size range. Specify the size range in the Size Start and Size End.
  
  
• SizeStart - Beginning of the size range
  
  
• SizeEnd - Ending of the size range.
  
  
• Random - Page heap allocations with probability. If selected, you need to enter in a RandRate.
  
  
• RandRate - Decimal integer in range [0..100] representing probability to make page heap allocation vs. a normal heap allocation.
  
  
• Backward - Catch backwards overruns. If selected, this will check buffer underruns.
  
  
• Unalign - No alignment for allocations.
  
  
• Traces - Collect stack traces
  
  
• Protect - Protect heap internal structures. Can be used to detect random corruptions but execution is slower. Note that this is turned off by default and should only be set to True by an advanced user who knows how to debug the problems that it may uncover.
  
  
• NoLock - Disable critical section verifier.
  
  
• Faults � Enable heap fault injection. Note that the preferred method for running fault injection is the Low Resource Simulation Stops.
  
  
• FaultRate - Probability (1..10000) for heap calls failures
  
  
• TimeOut - Time during process initialization (in milliseconds) when faults are not allowed.
  
  
• Addr - Page heap allocations for address range. If selected, please specify the address range in AddrStart and AddrEnd.
  
  
• AddrStart - Beginning of the address range
  
  
• AddrEnd - Ending of the address range
  
  
• UseLFHGuardPage - Turns on LFH guard pages, which is turned off by default.
  
  
• DelayFreeSize (MB) - Maximum amount of memory, in megabytes, to use for delayed free list. The Heap Verifier checks this list to detect double freeing of an allocation and the use of an allocation after it has been freed. The default value of this property varies by processor architecture.
  
  

Heap detects almost any heap related bug that is detectable. It is focused on corruption issues and not on leaks. The Page Heap tests in Application Verifier are not able to capture information about most heap memory leaks, so a different tool would be useful for that category of heap problem.

One of the great advantages of the Page Heap test in Application Verifier is that many errors can be detected in the instant they happen. For example, an off by one byte error at the end of a dynamically allocated buffer might cause an instant access violation. However, there are a few error categories that cannot be detected instantly and the error report is delayed until the block is freed.

The Page Heap functionality provides the following tests to Application Verifier:

• Invalid heap pointer - All Microsoft Win32 and NT level heap interfaces take as first parameter a pointer to the heap where the operation should happen. The page heap manager detects at the moment of the call an invalid heap pointer.
  
  
• Invalid heap block pointer - After a block is allocated it can be used as a parameter for several heap interfaces (most notably free() class of interfaces). The page heap manager detects immediately an invalid heap block pointer. See the debugging techniques section for a way to determine if the invalid address is just meaningless information or is a few bytes off.
  
  
• Multithreaded unsynchronized access to the heap - some applications call into a heap from multiple threads. This type of scenario requires setting a flag (by the user) that triggers acquiring a heap lock. The page heap manager detects this type of violation in the moment two threads attempt to call simultaneously into the heap.
  
  
• Assumptions about reallocation of a block at the same address - Although it is thoroughly documented that a reallocation operation is not guaranteed to return the same address, once in a while applications contain this assumption. This is especially the case when the reallocation reduces the size of the block. The page heap manager always allocates a new block during a reallocation and frees the old block. The free block is protected for R/W access and therefore any access to it raises an access violation.
  
  
• Double free - It is a bug noticed with high frequency. Heap blocks are freed several times. This is detected immediately by the page heap manager because on the second free the block does not have the proper prefix header and cannot be found among the allocated blocks. See the debugging techniques section for ways to figure out the stack trace of the first free operation. This error can be a variant of the reallocation problem because when the application frees what it thinks is the address of the block, that block was already freed as part of the reallocation.
  
  
• Access of block after free - The memory blocks freed are kept for a while by the page heap manager in a pool of protected memory. Any access to such a block raises an access violation. Based on the "locality" principle, it is expected to catch most of the problems if the free protected pool is large enough. If the freed block is still in the protected pool then the bug is caught instantly. If the memory was reused, the chances of finding the bug decrease considerably.
  
  
• Access after the end of allocated block - The page heap manager places an inaccessible page right after the allocated block. Any access after the end of the block raises an access violation. There is one little caveat. Some applications (for example, Microsoft Internet Explorer) expect allocations to be 8-byte aligned. This is a feature supported since the heap manager in Microsoft Windows NT 3.5. This means that a request size that is not 8-byte aligned gets an 8-byte aligned address and this leaves a few bytes after the end of the block that are still accessible. If the application corrupts only those few bytes then the error is caught only when the block gets freed by checking the block suffix pattern.
  
  
• Access before the start of allocated block - The page heap manager can be instructed through setting a flag to place the inaccessible page at the beginning rather than at the end of the block. Any access before the start of the block raises an access violation.
  
  

For more information, see the Heap details topic.