How to get native exception on .NET core or .NET 5

[diehell02]

I need to get the call stack when a crash occurs.

Our project is using C++/CLI to combine C# and C++ code.

The exception from C# and C++/CLI， we can use try-catch to get the exception.

But the exception from native C++, especially the exception that is considered unrecoverable, or occurs in another thread, like AccessViolationException, StackOverflowException.

int* p = nullptr;
*p = 123;

And I also see when the native exception occurs, the console will print this message and then the app crash:

Fatal error. System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
Repeat 2 times:
--------------------------------
   at <Module>.NativeCppDemo.MyNativeCppTestClass.memberFunctionAddFunCrash(NativeCppDemo.MyNativeCppTestClass*, Int32, Int32)
--------------------------------
   at ClrCrashTestNetCore.ClrTest.memberFunAddCrash(Int32, Int32, Boolean)
   at CsCrashDemoNetCore.Program.Run()
   at CsCrashDemoNetCore.Program.Main(System.String[])

This is the message that I want but I don't know how to get it in the code.
And I found this message when the exception occurs on another thread, it won't print on the console.

Do we have any method to get the exception information from native C++? Like has some interface to get the exception? Or using a profiler can get the call stack?

[danmoseley]

Can you use a native debugger, maybe set to break on native exception throw?

[diehell02]

Can you use a native debugger, maybe set to break on native exception throw?

My purpose is to get the crash information on the product when the crash occurs, in the production environment. Adding a debugger maybe is not suitable for us.
Do we have some interface or event that can get the exception? Don't need to only use in C#, in C++/CLI is ok, or in the daemon process, even add the clrprofiler is acceptable. But I don't know how to get it.

[hez2010]

I believe even you managed to get exception message, in this case you will only get a line segment fault as result.

You can configure your environment to generate core dump while crash happening, so that you can attach your debugger to the dump file to do analysis locally.

[diehell02]

I believe even you managed to get exception message, in this case you will only get a line segment fault as result.

You can configure your environment to generate core dump while crash happening, so that you can attach your debugger to the dump file to do analysis locally.

Yes, through analyze the dump file we can get the call stack fully, but the problem is that the dump file size is too huge, for our situation the size is more than 200M after zipping. So the best way is we can get the crash call stack directly.

[acaly]

Have you considered having your own debugger as another process to attach to your actual process? With a debugger you can get everything theoretically.

[diehell02]

Have you considered having your own debugger as another process to attach to your actual process? With a debugger you can get everything theoretically.

The purpose is to get the crash call stack on the production environment, using the debugger maybe is not a suitable option.

[acaly]

The purpose is to get the crash call stack on the production environment, using the debugger maybe is not a suitable option.

Why not? Debugger is basically a message loop. If you want to reliably get something when your application crashes, that's the best way. Many PC software (especially games) today use debugger for anti-reversing purpose in the shipped version.

[jkotas]

It will be addressed by ExceptionHandling.SetFatalErrorHandler proposed by #101560