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

Compare with Current View Page History

« Previous Version 2 Next »

In crash cases 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 https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools

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) with admin and change directory to the Windbg installation directory.

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

gflags /p /enable DasClientAgent.exe /full


Restart the service (net stop DasClientAgent /y && net start DasClientAgent)

Create a dump folder, for instance c:\dumps,


Get the pid of DasClientAgent, here it is 4320,



Now set up a crash capture,

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


After the crash, reset

gflags.exe -p /disable DasClientAgent.exe

Restart the service.



References

Finding process Heap Corruption using Windbg

SAVE OUR SOULS -TROUBLESHOOTING HEAP CORRUPTION THE CLASSIC WAY WITH GFLAGS AND WINDOWS DEBUGGER

Detecting Heap Corruption Using GFlags and Dumps