GFlags setting to catch heap corruption (other than Page Heap)?

Question

On one production site our application^(*) crashes repeatedly, but non-reproducibly. Analyzing the crash dumps clearly shows that it\'s a heap corruption: The crashes

Answer 1

"Enable Page Heap" from the gflags GUI enables full page heap verification which can cause the problem you describe. The gflags command line gives you more control and allows you to enable standard page heap verification which uses less memory but is less powerful. The command line also offers you the ability to to use a mix of standard and full using the /size, /dlls, and /address options.

Here are the options listed in the debugger.chm help file:

*To enable and configure page heap verification:

    gflags /p /enable ImageFile  [ /full [/backwards] | /random Probability | /size SizeStart SizeEnd | /address AddressStart AddressEnd | /dlls DLL [DLL...] ]  [/debug ["DebuggerCommand"] | /kdebug] [/unaligned] [/notraces] [/fault Rate [TimeOut]] [/leaks] [/protect] [/no_sync] [/no_lock_checks]*

Answer 2

1. IMHO the easiest way to control all this checking is using the ApplicationVerifier. You have a perfect UI and you can play around with all flags.
2. Heap Free checking is a good flag without too much overhead. So if a heap block is badly modified and the block is freed you get a break into the debugger. If the corruption occurs near the allocation and freeing of the block, this might help.
3. AFAIK "Heap parameter chechking" is just a lightweight "heap validation on call". I never had any success with this.
4. Heap tail checking and tagging is easy and fast. Works sometimes for me.

You know that you can control this on a per application base also with gflags.

gflags.exe /i Testapp.exe e0

But: The best way to find such problems is completely using the Debug-CRT... if it is possible for you. So if there is a chance to use you Debug-Version in the production environment, do it. Inside the Debug-CRT you again a lot of flags you can use and set....