0

I am using the DebugDiag to analyze a crash dump on windows.

This is the report summary description:

In XXXX.dmp the assembly instruction at msvcr120!abort+4a in C:\Windows\System32\msvcr120.dll from Microsoft Corporation has caused an unknown exception (0x40000015) on thread 26

And the call stack is:

ntdll!NtWaitForMultipleObjects+a 
KERNELBASE!WaitForMultipleObjectsEx+e8 
kernel32!WaitForMultipleObjectsExImplementation+b3 
kernel32!WerpReportFaultInternal+215 
kernel32!WerpReportFault+77 
kernel32!BasepReportFault+1f 
kernel32!UnhandledExceptionFilter+1fc 
msvcr120!_call_reportfault+b6 
msvcr120!abort+4a 
msvcr120!terminate+1e 
msvcp120!_Call_func$catch$0+13 
msvcr120!_CallSettingFrame+20 
msvcr120!__CxxCallCatchBlock+f5 
ntdll!RcConsolidateFrames+3 
msvcp120!_Call_func+14 
msvcr120!_callthreadstartex+17 
msvcr120!_threadstartex+102 
kernel32!BaseThreadInitThunk+d 
ntdll!RtlUserThreadStart+1d

Guys, what can I make of this crash dump?

Cheers,

Doron

DoronBM
  • 515
  • 1
  • 6
  • 17
  • `abort` is an effect, not the cause. The cause happened earlier somewhere between `msvcp120!_Call_func+14` and `msvcr120!__CxxCallCatchBlock+f5`. I woud try to get a dump on the first chance exception(s) using procdump from sysinternals and analyze those. – Lieven Keersmaekers May 17 '16 at 10:38
  • `dps poi($teb+8) poi($teb+4)` may help you determine what was being called a the time of the exception. Make sure the current thread is the one that caused the exception before running that command. – Marc Sherman May 17 '16 at 13:37

1 Answers1

1

You are using a C++ try catch statement which more or less adds the exception handling Code msvcr120!__CxxCallCatchBlock+f5 shows that.

kernel32!UnhandledExceptionFilter+1fc msvcr120!_call_reportfault+b6

The exception is then probably thrown and is not handled at your code. You may want to inspect the exception deeper in windbg with the source of the application. If this is a managed application then you may want to use SOS extension.

Addy
  • 731
  • 5
  • 15