Advanced Windows Debugging

You could avoid all the compiler Kung Fu and directly use windbg at runtime to detect memory leaks. See here for a little walk-through. windbg will tell you directly where the leak originates from. A very good book on this topic is Advanced Windows Debugging: Developing and Administering Reliable, Robust, and Secure Software.

I know that this is not a direct answer to your question, but I've tried the route you are trying now and dropped it pretty quickly.

I think you might want to buy Advanced Windows Debugging. There isn't anything nearly good enough on the web for you to learn this well.

http://www.amazon.com/Advanced-Windows-Debugging-Mario-Hewardt/dp/0321374460/ref=sr_1_1?ie=UTF8&qid=1305567440&sr=8-1

You can check out the book site here:

http://www.advancedwindowsdebugging.com/

For some other resources

From looking at the !heap documentation in the Debugging Tools for Windows help file and the heap docs on MSDN and a great excerpt from Advanced Windows Debugging, here's what I've been able to put together:

• HEAP_ENTRY: pointer to entry within the heap. As you found, there is an 8 byte header which contains the data for the HEAP_ENTRY structure. The size of the HEAP_ENTRY structure is 8 bytes which defines the "heap granularity" size. This is used for determining the...
• SIZE: size of the entry in terms of the granularity (i.e. the allocation size / 8)
• FLAGS: these are defined in winbase.h with explanations found the in MSDN link.
• USERPTR: the actual pointer to the allocated (or freed) object

You can, however see another process's memory you do need to be in kernel mode. The API makes it easy to do from User mode. Your choice.

Kernel mode stuff and useful links I've grabbed quickly:

• The main one: http://www.microsoft.com/whdc/driver/default.mspx
• OSR : http://www.osr.com/ and their book
• Windows Internals from MS and look at the 'Customers Who Bought This Item Also Bought'
• Advanced Windows Debugging
• A boat load of stuff from Dmitry Vostokov

Try AppVerifier and GFlags together to find Page Heap corruption.

You'll likely need WinDbg as your debugger instead of Visual Studio to debug.

I also recommend this book on advanced Windows debugging for tracking down crashes such as the one you are hitting.