Visual Studio - how to find source of heap corruption errors

I wonder if there is a good way to find the source code that causes a heap corruption error, given the memory address of the data that was written 'outside' the allocated heap block in Visual Studio;

Dedicated (0008) free list element 26F7F670 is wrong size (dead)

(Trying to write down some notes on how to find memory errors)

Solution 1:

Begin with installing windbg:

http://www.microsoft.com/whdc/Devtools/Debugging/default.mspx

Then turn on the pageheap like this:

gflags.exe /p /enable yourexecutable.exe /full

This will insert a non writable page after each heap allocation.

After this launch the executable from inside windbg, any writes outside the heap will now be caught by this debugger. To turn of the pageheap afterwards use this:

gflags.exe /p /disable yourexecutable.exe

More info on how to use the pageheap here.

Solution 2:

For Window 10 you could enable the PageHeap option in the GFlags Tool, this tool is included as part of the Debugging Tools for Windows.

The Page Heap options in GFlags lets you select standard heap verification or full-page heap verification. Beware, the full heap verification uses a full page of memory for each allocation so it can cause system memory shortages.

To enable the Page Heap in GFlags:

•To enable standard page heap verification, the standard version will write a pattern at the end of each heap allocation and then examine the pattern when the allocations are freed.

To verify all processes use:

gflags /r +hpa

gflags /k +hpa

for a single process use:

gflags /p /enable ImageFileName

•To enable full page heap verification for one process, this option places an inaccessible page at the end of each allocation so that the program stops immediately if it tries to accesses memory beyond the allocation, this should only be used on a single process due to the heavy memory consumption.

gflags /i ImageFileName +hpa

gflags /p /enable ImageFileName /full

The two commands above are interchangeable.

Note: All page heap settings mentioned above are system wide settings stored in the registry (except /k) and remain effective until you change them. The /k setting is a Kernel flag setting are set for this session and will be lost when Windows shuts down

Another helpful tool is the Application Verifier, but this is not part of the Debugging Tools for Windows, rather it is included in the Windows Software Development Kit (SDK).

Solution 3:

Maybe you can try Microsoft's Application Verifier. It solved a similar problem for me once,by turning on extra checks on heap operations. In my opinion, the randomness of corrupted address is because the heap can be 'subtly' damaged, and the problem won't show up until something big happens to the heap (like massive allocation/free).

Solution 4:

You could set a breakpoint on a write to the memory address. The debugger will then show you the code that writes to the location, but you still need to work out which of the writes are causing the problem.