I an observing a similar problem in a much larger program to something that can be replicated with the code below:
int main() { printf("starting application"); std::string str {"This is my string"}; printf("The last char is %d", (int)(str.at(str.size()))); return 0; } This obviously crashes with an uncaught std::range_error
To debug this problem I have set up Windows Error reporting and as expected it is creating a minidump. However when I load the minidump into Visual Studio to generate a call stack I get the following:
msvcr120.dll!abort() Line 88 C msvcr120.dll!terminate() Line 96 C++ test2.exe!__CxxUnhandledExceptionFilter(_EXCEPTION_POINTERS * pPtrs) Line 39 C++ KERNELBASE.dll!_UnhandledExceptionFilter@4() Unknown ntdll.dll!__RtlUserThreadStart() Unknown ntdll.dll!__RtlUserThreadStart@8() Unknown which is totally useless in identifying the root cause of the problem.
What I am after is a callstack like:
KernelBase.dll!_RaiseException@16() Unknown [External Code] msvcp120.dll!std::_Xout_of_range(const char * _Message) Line 24 C++ test2.exe!main() Line 16 C++ [External Code] (when running with a debugger) Which identifies the place that the std::range_error occurred. Does anyone know how to configure Windows Error Reporting not to hide the error as it does in the top callstack?
Using Visual Studio 2013
On Linux using g++, the application core dumps and when the core is run in gdb I get a callstack that goes to where the exception was thrown
2 Answers
Answers 1
You're mixing two Microsoft products, Windows and Visual Studio.
Windows Error Reporting deals with Win32 errors, such as unhandled SEH (natove) exceptions. The Visual Studio CRT is responsible for std::range_error.
You're proposing a Windows Error Reporting setting that affects the CRT. That can't work. Windows Error Reporting can't even assume a Microsoft CRT is present.
Instead, approach this from the CRT side. The relevant function in the CRT is std::set_terminate(&your_handler)
[edit] Since you want to break into the debugger (which is a Windows thing, not CRT) you'd call FatalExit
Answers 2
There is a trick to get to the "original" stack of the SEH exception. When kernel terminates the program (this is what your stack shows), it still saves the context record of original stack. This article describes how to get to this record using WinDBG: https://support.microsoft.com/en-us/help/313109/how-to-find-the-problem-exception-stack-when-you-receive-an-unhandlede
If you expect to do this often, you can probably write a WinDBG macro for this.
0 comments:
Post a Comment