Retail Products:

How to debug Heap corruptions

What is Heap corruption

Heap corruption is a very annoying problem because the crash doesn’t suggest where the corruption is.
When the corruption occur you usually see these methods in the trace: nh_malloc_dbg, nh_malloc_dbg_impl

The corruption usualy occurs when someone deleted a memory chunk and later wrote on that freed memory because of failure to nullify the pointer or because of multithreading race conditions. Later in the program’s life when the heap manager tries to allocate memory because of a request from the user, the manager finds out that a memory was written after it was released and crashes. A sample crashing code would look like this:

char* pData=new char;
delete pData;
*pData=0;


char* pData2=new char; – This is where you will get the crash

What to check before trying to debug

Things to check for before using this technique:

  • Code generation, check that if you are using multithreading that your CRT is multithreaded as well (it’s under C++/code generation in the project settings).
  • In multithreaded environment make sure that your code is thread safe, keep in mind that for some libraries “code safe” means that it has no statics but multiple threads sharing same data structure should be synchronised by you.

How to debug

Debugging this is very tricky using only debuggers and from my experience all the memory leak detection tools never really help in finding such problems! The only way I found to track the problem is to use Microsoft’s little memory helper called: Pageheap. what this tool does is to allocate every memory on its own page which means that that when accessing it after deleting it, it will generate an access violation and we can see exactly where it occured, the problem with this technique that it slows the application and in case the bug is because of racing condition, the race might not occur because of the speed reduction.

Enabling pageheap

To enable pageheap for your application run:

pageheap /enable yourprocess.exe /full

Now run your process (make sure you allow the debugger to crash on 0xc0000005 access violations) and you will see exactly where’s the offending code.
You will be able to know that the new memory scheme is in place by the fact that your process will take up to three time the normal memory it usually takes.

Disabling pageheap

Once you’re done with debugging your application you revert back to normal memory usage by running:

pageheap /disable yourprocess.exe