Heap and early crash dump: pattern cooperation

The following error was reported when launching an application and no configured default postmortem debugger was able to save a crash dump:

The application failed to initialize properly (0x06d007e). Click on OK to terminate the application.

The process memory dump captured manually using userdump.exe when the error message box was displayed didn’t show anything helpful on stack traces:

0:000> ~*kL

.  0  Id: 310.1ab8 Suspend: 1 Teb: 7ffdf000 Unfrozen
ChildEBP RetAddr 
0012fd14 7c8284c5 ntdll!_LdrpInitialize+0x184
00000000 00000000 ntdll!KiUserApcDispatcher+0x25

   1  Id: 310.1ec0 Suspend: 1 Teb: 7ffde000 Unfrozen
ChildEBP RetAddr 
0820fcb0 7c826f4b ntdll!KiFastSystemCallRet
0820fcb4 7c813b90 ntdll!NtDelayExecution+0xc
0820fd14 7c8284c5 ntdll!_LdrpInitialize+0x19b
00000000 00000000 ntdll!KiUserApcDispatcher+0x25

However, one of last error values was access violation (Last Error Collection pattern):

0:000> !gle -all
Last error for thread 0:
LastErrorValue: (Win32) 0x3e6 (998) - Invalid access to memory location.
LastStatusValue: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

Last error for thread 1:
LastErrorValue: (Win32) 0 (0) - The operation completed successfully.
LastStatusValue: (NTSTATUS) 0 - STATUS_WAIT_0

It was suspected that access violation errors were handled by application exception handlers (Custom Exception Handler pattern) and it was recommended to catch first-chance exception crash dumps (Early Crash Dump  pattern) and indeed there was one such exception:

0:000> r
eax=00000000 ebx=00000000 ecx=00000000 edx=00157554 esi=00000080 edi=00000000
eip=7c829ffa esp=0012ed48 ebp=0012ef64 iopl=0 nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000  efl=00010246
ntdll!RtlAllocateHeap+0x24:
7c829ffa 0b4310          or      eax,dword ptr [ebx+10h] ds:0023:00000010=????????

0:000> kL
ChildEBP RetAddr 
0012ef64 7c3416b3 ntdll!RtlAllocateHeap+0x24
0012efa4 7c3416db msvcr71!_heap_alloc+0xe0
0012efac 7c3416f8 msvcr71!_nh_malloc+0x10
0012efb8 67741c01 msvcr71!malloc+0xf
[...]

- Dmitry Vostokov @ DumpAnalysis.org -

Leave a Reply