Performance Zone is brought to you in partnership with:

Sasha Goldshtein is a Senior Consultant for Sela Group, an Israeli company specializing in training, consulting and outsourcing to local and international customers.Sasha's work is divided across these three primary disciplines. He consults for clients on architecture, development, debugging and performance issues; he actively develops code using the latest bits of technology from Microsoft; and he conducts training classes on a variety of topics, from Windows Internals to .NET Performance. You can read more about Sasha's work and his latest ventures at his blog: http://blogs.microsoft.co.il/blogs/sasha. Sasha writes from Herzliya, Israel. Sasha is a DZone MVB and is not an employee of DZone and has posted 203 posts at DZone. You can read more from them at their website. View Full User Profile

Page Heap: A Useful Diagnostic Option for Windows Apps.

07.26.2012
| 4513 views |
  • submit to reddit

Page Heap is an extremely useful diagnostic option that you can enable for your Windows application using GFlags or Application Verifier. When Page Heap is enabled, each heap allocation is placed on the end of a page boundary, and the subsequent page is marked as PAGE_NOACCESS. Any buffer overruns are therefore immediately caught.

While Page Heap is very useful, its cost is often too high for use in production applications. Fortunately, there is a more lightweight option, called (appropriately) Light Page Heap, that results in a smaller overhead at the expense of catching memory errors at a later point.

To enable Page Heap and perform additional configuration, such as switching to Light Page Heap or specifying which DLLs or memory ranges should use the Page Heap settings, use Application Verifier. After selecting your executable and choosing the Basics | Heaps test, right-click Heaps and select Properties for a variety of additional options.

image

image

When Full Page Heap is enabled, a buffer overrun manifests itself immediately as an access violation:

 

(c44.6cc): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00aa3b04 ebx=602b2435 ecx=00000043 edx=0811b4fc esi=08bbf000 edi=00000064
eip=602b2473 esp=0946fe34 ebp=0946fe3c iopl=0         nv up ei pl nz ac pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010216
MSVCR100!wcscpy_s+0x3d:
602b2473 66890c02        mov     word ptr [edx+eax],cx    ds:002b:08bbf000=????
0:001> k
ChildEBP RetAddr
0946fe3c 00aa1a1e MSVCR100!wcscpy_s+0x3d
0946fe54 00aa1730 BatteryMeter!CPUInformation::CPUInformation+0x2e
0946fe80 765183db BatteryMeter!TemperatureAndBatteryUpdaterThread+0x90
0946fe8c 77899a3f KERNEL32!BaseThreadInitThunk+0xe
0946fed0 77899a12 ntdll!__RtlUserThreadStart+0x72
0946fee8 00000000 ntdll!_RtlUserThreadStart+0x1b 

With Light Page Heap, on the other hand, you catch the error only when the overrun buffer is freed – Application Verifier detects that a suffix pattern at the end of the heap block was corrupted:

=======================================
VERIFIER STOP 0000000F: pid 0x1658: Corrupted suffix pattern for heap block.

    06191000 : Heap handle used in the call.
    089F32B0 : Heap block involved in the operation.
    000011D0 : Size of the heap block.
    089F4480 : Corruption address.


=======================================
This verifier stop is not continuable. Process will be terminated
when you use the `go' debugger command.

=======================================

(1658.c08): Break instruction exception - code 80000003 (first chance)
eax=000001a1 ebx=00000000 ecx=059cd7e0 edx=08bef4c1 esi=62ceda28 edi=000001ff
eip=62ce3355 esp=08bef798 ebp=08bef99c iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
vrfcore!VerifierStopMessageEx+0x578:
62ce3355 cc              int     3
0:001> k
ChildEBP RetAddr
08bef99c 62ce7d85 vrfcore!VerifierStopMessageEx+0x578
08bef9c4 61bd9922 vrfcore!VfCoreRedirectedStopMessage+0x88
08befa28 61bd9d5a verifier!AVrfpDphReportCorruptedBlock+0x1c2
08befa84 61bda252 verifier!AVrfpDphCheckNormalHeapBlock+0x11a
08befaa4 61bd8be3 verifier!AVrfpDphNormalHeapFree+0x22
08befac8 7791c526 verifier!AVrfDebugPageHeapFree+0xe3
08befb14 778c6a61 ntdll!RtlDebugFreeHeap+0x2f
08befb98 7788dd8e ntdll!RtlpFreeHeap+0x74
08befbbc 62cea6df ntdll!RtlFreeHeap+0x206
08befbd4 602b016a vrfcore!VfCoreRtlFreeHeap+0x16
08befbe8 00aa1784 MSVCR100!free+0x1c
08befc18 765183db BatteryMeter!TemperatureAndBatteryUpdaterThread+0xe4
08befc24 77899a3f KERNEL32!BaseThreadInitThunk+0xe
08befc68 77899a12 ntdll!__RtlUserThreadStart+0x72
08befc80 00000000 ntdll!_RtlUserThreadStart+0x1b

When chasing heap corruptions in real production applications, combining Light Page Heap with the ability to configure Page Heap only for suspect modules makes it realistic to catch the memory corruption without completely sacrificing application performance.

 

 

 

Published at DZone with permission of Sasha Goldshtein, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)