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