Remember in Part I, we identified the issue to be heap corruption in msvcrt heap. And then I decided to use pageheap with full switch to capture another round of IIS crash dump and I noticed there was huge performance degradation to customer’s application. So we have to go with normal switch and were able to capture a 2nd chance exception dump. The culprit turns to be in 3rd party module.
FAILED_INSTRUCTION_ADDRESS:
safeagent+1ae10
1001ae10 ?? ???
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: safeagent!unloaded+1ae10
FOLLOWUP_NAME: wintriag
MODULE_NAME: safeagent
IMAGE_NAME: safeagent.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 45f51b03
FAILURE_BUCKET_ID: BAD_INSTRUCTION_PTR_c0000005_safeagent.dll!unloaded
BUCKET_ID: APPLICATION_FAULT_BAD_INSTRUCTION_PTR_INVALID_POINTER_READ_BAD_IP_safeagent!unloaded+1ae10
Followup: wintriag
---------
The call stack was collapsed:
0:007> knL
# ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
00 088bc188 00000000 <Unloaded_safeagent.dll>+0x1ae10
Summary:
========
We are lucky in this case as we were able to capture something with pageheap. The story could turn to be very complicated when pageheap kept silent. I will share with you next time when I encounter such cases.