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开发者_StackOverflow (0008) free list element 26F7F670 is wrong size (dead)

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

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.

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).

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).

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.

It's probably too late but if it compiles with gcc and can run on linux you may use valgrind to find the source of the problem (i don't remember the flags, i only used it once with great success).

more info about Gflags and PageHeap(which helped a lot): http://msdn.microsoft.com/en-us/library/windows/hardware/ff549561%28v=vs.85%29.aspx

I am assuming C++ as the language.

If the error is reproducible and the corrupted address is always the same, you can put a data breakpoint to stop the program when writing at this address.

Make sure all libraries you are linking to are compiled in the same CLR version as the application you are running - all in Release or all in Debug.

When you compile in either Debug and Release you are actually targeting two different versions of the C runtime library. These versions are quite different and they use different strategies for allocating memory and they use different heaps. But the most important thing to know is that they are NOT compatible with one another.

The Release C runtime library allocated memory as expected, whereas the Debug will add extra information, such as guard blocks to track buffer overflow and the location that called the allocation function, and in turn it allocates more memory than the Release.

If your are linking your application to a mix of DLLs which were built in Release and Debug, you will most likely end up trying to delete an object in one CLR which was created in another. This means you will be trying to free more or less memory than what was allocated to the object and this can corrupt the heap.

You should build your application, as well as attach to libraries which are built under the same configuration, either Release or Debug.

This problem can occur especially in modules that are being compiled with different compilers.

There is a way to work around, which I will mention but do not recommend. If for some reason you still need to build in different modes, this work around will allows for all memory to be allocated and freed from the same shared heap. The API GetProcessHeap will allow you to access the shared heap throughout the different modules. By using the HeapAlloc & HeapFree you can allocate and free memory in the shared heap. Note: the HeapAlloc and HeapFree should replace all calls to malloc and free in your application.