Use Application Verifier to detect a heap bug

What happens if you run a code like this?

int main(){
    unsigned char* p = new unsigned char[16];

    // fill 17 bytes where only 16 bytes are allocated!
    memset(p, 0xff, 17);
    delete [] p;

Even if you compile the code and run the program, you don’t see any errors – well, at least in my environment. It’s quite bad because you cannot easily detect the error before shipping.

That’s why it’s recommendation practice to use Application Verifier. Actually, I periodically run overnight stress-test script for my programs with Application Verifier enabled.

Let’s see how the Application Verifier detects the problem. First of all, you need to install the Application verifier.

Then, start the verifier, select [File]->[Add Application] to add your program, and hit [Save] button.


That’s pretty much it. You can exit the Application Verifier GUI.

If you run the program again, you will see the debugger is broken in.


Microsoft (R) Windows Debugger Version 6.8.0004.0 X86
Copyright (c) Microsoft Corporation. All rights reserved.

*** wait with pending attach
Symbol search path is: SRV*c:symbols*
Executable search path is:
ModLoad: 00400000 00406000   S:reposbranchesmoto_sandbox_2008_11_10rzxxxsandboxbig_memheap_corrupt.exe
ModLoad: 7c900000 7c9af000   C:WINDOWSsystem32ntdll.dll
ModLoad: 5ad10000 5ad59000   C:WINDOWSSystem32verifier.dll
ModLoad: 00370000 00398000   C:WINDOWSSystem32vrfcore.dll
ModLoad: 003a0000 003d9000   C:WINDOWSSystem32vfbasics.dll
ModLoad: 7c800000 7c8f6000   C:WINDOWSsystem32kernel32.dll
ModLoad: 78130000 781cb000   C:WINDOWSWinSxSx86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.3053_x-ww_b80fa8caMSVCR80.dll
ModLoad: 77c10000 77c68000   C:WINDOWSsystem32msvcrt.dll
ModLoad: 77dd0000 77e6b000   C:WINDOWSsystem32ADVAPI32.DLL
ModLoad: 77e70000 77f02000   C:WINDOWSsystem32RPCRT4.dll
ModLoad: 77fe0000 77ff1000   C:WINDOWSsystem32Secur32.dll
(46c.e20): Break instruction exception – code 80000003 (!!! second chance !!!)
eax=000001ff ebx=0037c100 ecx=7c91eab5 edx=000001cb esi=00000000 edi=000001ff
eip=7c90120e esp=0012f918 ebp=0012fb18 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
7c90120e cc              int     3

You can now start debugging as usual. Probably, the first step is to use !analyze -v command. In this easy example, the red line below unveils the exact cause of the problem.


00401016 884810          mov     byte ptr [eax+10h],cl

EXCEPTION_RECORD:  0012fc90 — (.exr 0x12fc90)
ExceptionAddress: 00401016 (heap_corrupt!main+0x00000016)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000001
   Parameter[1]: 02367000
Attempt to write to address 02367000



PROCESS_NAME:  heap_corrupt.exe

CONTEXT:  0012fcac — (.cxr 0x12fcac)
eax=02366ff0 ebx=00000000 ecx=ffffffff edx=00000000 esi=00000001 edi=0040338c
eip=00401016 esp=0012ff78 ebp=0012ffc0 iopl=0         nv up ei ng nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010286
00401016 884810          mov     byte ptr [eax+10h],cl      ds:0023:02367000=??


About Moto

Engineer who likes coding
This entry was posted in Advanced Debugging. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s