Troubleshooting CRT heap corruption

This article focuses on troubleshooting a heap corruption caused by writing into the next allocated block. Heap corruption comes into notice when the overridden memory is accessed, leaving in a state where it becomes hard to figure out the original code that is overriding the memory.


In this scenario, call stack could look like

0:000> kp

ChildEBP RetAddr 

0:000> kb

ChildEBP RetAddr  Args to Child             

0012c2f4 7c91a3bc 01660000 01d0b000 0012c320 ntdll!RtlpFindAndCommitPages+0x116

0012c32c 7c911917 01660000 00000300 0012eb04 ntdll!RtlpExtendHeap+0xa6

0012c55c 00f4103e 01660000 00000000 000002f4 ntdll!RtlAllocateHeap+0x623

0012c578 00f4fd76 000002f4 5a7fcbb3 0012eb04 msvcr90d!_heap_alloc_base+0x5e

0012c5c0 00f4fb2f 000002d0 00000001 00000000 msvcr90d!_nh_malloc_dbg+0x2c6

0012c5e0 00f4fadc 000002d0 00000000 00000001 msvcr90d!_nh_malloc_dbg+0x7f

0012c608 00f5b25b 000002d0 00000000 00000001 msvcr90d!_nh_malloc_dbg+0x2c

0012c628 00f3d691 000002d0 cccccccc cccccccc msvcr90d!malloc+0x1b

0012c644 007ab543 000002d0 cccccccc 0012c690 msvcr90d!operator new+0x11

0012eb14 0073b367 MyApp!DummyFun


01660000 is the heap used by msvcr90d.dll in this case


0:000> !heap -av 01660000

Index   Address  Name      Debugging options enabled

 12:   01660000

    Segment at 01660000 to 01670000 (00010000 bytes committed)

    Segment at 01d00000 to 01e00000 (00011000 bytes committed)

    Flags:                00001002

    ForceFlags:           00000000

    Granularity:          8 bytes

    Segment Reserve:      00200000

    Segment Commit:       00002000

    DeCommit Block Thres: 00000200

    DeCommit Total Thres: 00002000

    Total Free Size:      00000089




        0166e8e0: 00048 . 00300 [01] - busy (2f4)

        0166ebe0: 00300 . 00048 [01] - busy (3c)

        0166ec28: 00048 . 00048 [01] - busy (3c)

        0166ec70: 00048 . 00048 [01] - busy (3c)

        0166ecb8: 00048 . 00300 [01] - busy (2f4)

        0166efb8: 00300 . 00030 [01] - busy (25)

        0166efe8: 281a8 . 17188 [01] - busy (1717c)



    PreviousSize field does not match Size field in previous entry

    Entry->PreviousSize == 0x2e31

    PreviousEntry->Size == 0x60

##The above errors were found in segment at 0x01660640


Looking at the 0166efe8 memory block, it is clear that the current size of previous block ‘00030’  is not matching with the previous size ‘281a8’. This infers that 0166efe8 is corrupted and previous size field is overridden by some data.  


_ CrtMemBlockHeader is the block header structure used to store the debug heap's bookkeeping information, for more information


0:000> dt msvcr90d!_CrtMemBlockHeader 0166efb8+8

   +0x000 pBlockHeaderNext : 0x0166ecc0 _CrtMemBlockHeader

   +0x004 pBlockHeaderPrev : 0x0166eff0 _CrtMemBlockHeader

   +0x008 szFileName       : (null)

   +0x00c nLine            : 0

   +0x010 nDataSize        : 1

   +0x014 nBlockUse        : 1

   +0x018 lRequest         : 3686

   +0x01c gap              : [4]  "???"


0:000> dt msvcr90d!_CrtMemBlockHeader 0166efe8+8

   +0x000 pBlockHeaderNext : 0x0166efc0 _CrtMemBlockHeader

   +0x004 pBlockHeaderPrev : 0x0166f028 _CrtMemBlockHeader

   +0x008 szFileName       : (null)

   +0x00c nLine            : 0

   +0x010 nDataSize        : 8

   +0x014 nBlockUse        : 1

   +0x018 lRequest         : 3687

   +0x01c gap              : [4]  "???"


The reason behind adding 8 bytes is that, each memory block in a given segment has 8 bytes metadata associated with it. The metadata is used by the heap manager to effectively manage the heap blocks within a segment.


lRequest is the allocation count. The above msvcr90d!_CrtMemBlockHeader structures show that they are adjacent allocations (3686 & 3687). If the corruption is in the same spot and allocation numbers are sequential, _CrtSetBreakAlloc(3686) can be used to determine the code that is overriding the memory 0166efe8 and how that block is being corrupted.


Call _CrtSetBreakAlloc(3686) at the code startup for ex: main(), start debugging(F5) the code and this should break the debugger when 0166efb8 memory block is allocated. Once the debugger breaks, code could be reviewed for two things

1) How many bytes are allocated

2) Are there any chances that suspected buffer could overflow.


For Example:

char *ptr = new char;


strcpy(ptr, source);   //where ‘source’ variable holds more than one character.


Please make a note that 3686 & 3687 may be different when its debugged second time, but it’s very rare case.


Skip to main content