What is the symbol `myLibrary!__scrt_stub_for_is_c_termination_complete+0x12345`

Question

The symbol myLibrary!__scrt_stub_for_is_c_termination_complete+0x12345 appears in the stack trace of a crashed application. It is C++ compiled with MSVC2015 and heavily uses Qt.

myLibrary does not explicitly implement anything of that name.

Google shows some hits on this name, so apparently it is not particular to this one application. But I cannot find an explanation of it.

Journal

This is explained here §SEH. – Promisee

@Promisee In one of the code snippets the symbol name appears. But I see no reference to it in the text nor any kind of hint to an explanation. – Journal

Can you show more functions in the stack trace? At the least the function that calls __scrt_stub_for_is_c_termination_complete and the function that it calls. Also was the CRT linked statically (.LIB) or dynamically (.DLL)? Can you show the assembly code of __scrt_stub_for_is_c_termination_complete? – Verjuice

try running DrMemory. You can and download it from here – Talia

Answer 1

That is a "no idea where it crashed" diagnostic. The +0x12345 offset is far too large. Not uncommon at all, you need good PDBs to get accurate stack traces. Without them it doesn't know anything about the code you wrote and can only go by named DLL entrypoints.

Since the crash appears to be detected in the C runtime library, you might well get lucky by enabling the Microsoft Symbol Server and let it produce the PDB you need. Assuming you opened the minidump in VS, use Tools > Options > Debugging > Symbols to enable the server. General and WinDbg advice is available in this MSDN page.

Arundinaceous

Thank you! But I already have a symbol name and I want to know what this function does, whether it is something the compiler might insert into my code. I know by now that it is from msvcrt.dll. – Journal

You have the source code on your machine, just search the vc/crt/src directory for "_is_c_termination_complete". You ought to end up in utility.cpp, just goo that runs when a DLL unloads and takes care of cleanup. A pretty typical reason you'd see it back in a stack trace is when a program bombs due to a corrupted heap at program exit. Dangerous to force me to guess at the reason btw, as is guessing that it actually has anything to do with that function, the core of this answer. – Arundinaceous

Answer 2

Is a library name : myLibrary
Is a function name : __scrt_stub_for_is_c_termination_complete
Is a distance from function offset : +0x12345

If you enter the disassembly mode, then you can see a function's address

Also you can see in the (quick)watch to function name, same as disassembly

you can assuming exception raised from specific function and which line.

Watch out : If you debug in Release build , it would be hard to find which code raise the exception. In this case you can compare your assembly between Debug and Release (I cannot explain how it works 'til describing.). Use Debug Build to ease to Debug.

Happy Coding :)

Raphaelraphaela