You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

When a crash is caused by heap corruption, the crash stack trace is often from a thread that fell victim to heap corruption caused by other code. This can easily lead to false assumptions and wasted time diagnosing the crashing thread's call stack.

If heap corruption is suspected, a technique known as Full Page Heap checking can be used to locate the culprit. Enabling Full Page Heap should be avoided on most production machines due to extreme memory and CPU overhead. If possible, reproduce the issue in a test environment and debug there.

Use the steps below to enable Full Page Heap checking and find the offending code.

Download WinDBg standalone (still through SDK)  from

Only tick the component, "Debugging Tools for Windows"

By default, it is installed into the folder, C:\Program Files (x86)\Windows Kits\10\Debuggers\x64

Open a command window (cmd.exe) as admin and change directory to the Windbg installation directory.

Run this command (replace the .exe name with the one you need to debug) , e.g. DasClientAgent.exe

gflags /p /enable DasClientAgent.exe /full

Restart the service, e.g. DasClientAgent

net stop DasClientAgent 

net start DasClientAgent

Find the PID of DasClientAgent using the Task Manager, e.g. 4320,

and create a folder for saving dump files, for instance: c:\dumps,

Now, enable crash capture,

adplus -crash -p <pid> -o c:\dumps

(Replace <pid> with the PID of the DasClientAgent found in the last step)

Then, wait for the crash to happen.

After the crash has happened, disable crash capture,

gflags.exe -p /disable DasClientAgent.exe

And restart the service, e.g. DasClientAgent

net stop DasClientAgent 

net start DasClientAgent


Finding process Heap Corruption using Windbg


Detecting Heap Corruption Using GFlags and Dumps