1

I'm looking at a crash dump from a C++ app and can see that the application crashed with FAST_FAIL_FATAL_APP_EXIT.

The stack frame below suggests that an unhandled exception ntdll!RcConsolidateFrames+0x6.

I'm wondering if you could help point me in the right direction on how to go about tracking where the exception occurred.

msvcr120!abort+0x34
msvcr120!terminate+0x1e
msvcp120!_Call_func$catch$0+0x13
msvcr120!_CallSettingFrame+0x20
msvcr120!__CxxCallCatchBlock+0xf5
ntdll!RcConsolidateFrames+0x6
msvcp120!_Call_func+0x14
msvcr120!_callthreadstartex+0x17
msvcr120!_threadstartex+0x102
kernel32!BaseThreadInitThunk+0x14
ntdll!RtlUserThreadStart+0x21
Ol1v3r
  • 758
  • 1
  • 10
  • 23
  • 1
    It looks like something went wrong in `CallSettingFrame()`, but without symbol files I don't think you might be able to retrieve more information. By the way, is this a small crash dump or a full memory dump? (Not that it matters for this particular situation, but if your application tends to keep crashing, full memory dumps give more information and are useful for root cause analysis) – Dominique Oct 20 '20 at 09:21
  • Small dump file, and cannot reproduce the crash, so this is all I have to go on. I'll see if I can get more out of *CallSettingFrame()* as you said I doubt it. – Ol1v3r Oct 20 '20 at 09:28
  • 1
    It never hurts to run an `!analyze -v` and/or look at `.exr -1` – Lieven Keersmaekers Oct 20 '20 at 10:23
  • Related: https://stackoverflow.com/questions/37272549/windows-crash-dump-analysis – Thomas Weller Oct 20 '20 at 10:39
  • Related: https://stackoverflow.com/questions/61928563/difference-in-behavior-between-msvc-2010-compiled-application-and-msvc-2019-comp – Thomas Weller Oct 20 '20 at 10:41
  • 1
    @LievenKeersmaekers: does a call stack look like this when asynchronous exception handling /EHa is enabled? Otherwise I would expect a lot more function calls on the stack. – Thomas Weller Oct 20 '20 at 10:44
  • Already ran !analyze -v and .exr -1, nothing relavent to help track the source of the issue. Thanks for the links, I had already gone through them. I'll look into the async exception handling comment seems interesting. – Ol1v3r Oct 20 '20 at 10:51
  • @andI'msureI'mmissingsome - Not sure if that's an observation or a question you have for me but if it's a question: if *you* don't know, then I definitely don't know! :) – Lieven Keersmaekers Oct 20 '20 at 10:56
  • That was an observation, I had not considered that :) – Ol1v3r Oct 20 '20 at 13:37
  • @LievenKeersmaekers: oh, thanks for the compliment. Your observation might be biased. I'm definitely a C# guy and know too little about C++. Still learning C++. – Thomas Weller Oct 20 '20 at 14:27

1 Answers1

3

The call stack has two clues; $catch$ and terminate. That hints at an uncaught exception, at least an exception not caught by your code. There are two main cases to consider here: Either you missed a handler, or you couldn't catch the exception because it was thrown from a destructor.

To distinguish between these two cases, you can add your own catch(...) { std::terminate();} at top level, for all thread entry points. This will only catch the first case. If the exception continues to happen with the same call stack, you should suspect a destructor.

MSalters
  • 173,980
  • 10
  • 155
  • 350