What is ntdll.dll!RcConsolidateFrames?

Question

I have a call stack like below from my dump file. I want to find my code in the call stack, but I can't. What is start point to analyze my dump? Link option of my program is release/Od.

msvcr120.dll!abort() 
msvcr120.dll!terminate()
msvcp120.dll!_Call_func$catch()
msvcr120.dll!_CallSettingFrame()
msvcr120.dll!__CxxCallCatchBlock(_EXCEPTION_RECORD * pExcept=0x0000002885f9b010)
ntdll.dll!RcConsolidateFrames()
msvcp120.dll!_Call_func(void * _Data=0x00000028835d5ce0)
msvcr120.dll!_callthreadstartex()
msvcr120.dll!_threadstartex(void * ptd=0x000000288366e410)
kernel32.dll!BaseThreadInitThunk()
ntdll.dll!RtlUserThreadStart()

Sinusoid

RcCosolidateFrames is part of the exception handling code on Windows. Your program has some problem with its exception handling logic (like throwing a new exception when another exception is in progress or something). – Dirty

thank you for your hint! I found a unhandled exception in my code.:) – Sinusoid

I can see the exact same in WinDBG, is there a way to narrow down where the exception is occuring in the code using the dump? – Moneywort

@OliverCiappara - See the link in my answer for some more info (that I quite frankly cannot really follow). Maybe you can find something there whether it's possible to narrow the original location down from the info in the dump. – Jeffry

Answer 1

TL;DR: If you re-throw; the call stack will not show the original location, but something further up the stack and ntdll.dll!RcConsolidateFrames().

---

You will find ntdll.dll!RcConsolidateFrames() in your call stack for an unhandled exception instead of the actual location when the code uses catch(ANYTHING) + throw; in an x64 binary.

You see, if you catch and re-throw, the original call stack has been already unwound, and when you then throw; it will re-throw the original exception, but the call stack information is now messed up.

My observations for MSVC is that this will always happen with any throw; that is then unhandled and leads to a dump file. Specifically:

• It does not matter whether you use catch(...) or catch(cppTypeEx&)
• It does not matter whether it is a C++ exception (with /EHsc or /EHa) or a SEH exception (with /EHa).
• It will look like this in the debugger as well as in a dump file.

Bottom line: throw;will mess up your call stack

Jeffry

Do you know if there’s a way to get the original stack trace from certain types of exceptions like winrt::hresult_error? According to this article a winrt::hresult_error will record a stack trace for the current thread as part of being thrown as a "stowed exception", but I haven’t found a way to retrieve this stack trace. – Tinner

@Tinner - well that would be quite a separate question, wouldn't it. I'm not familiar with winrt, but as Raymond mentions Ro­Originate­Error I'd start with the docs on that function. If you write up a separate question for this, it's fine to drop a link here. – Jeffry