Fatal error instead of calling Unhandled Exception Filter

[awbushnell]

Description

We have an X64 Windows native application that also mixes in .netcore code. As part of our application we make use of unhandled Exception filters to collect runtime crash data from production uses of the product. We recently have moved from .netFramework 4.8 to .netCore version 7 and working on 8. We have found an issue where under certain circumstances, when an access violation occurs in the code, our handler no longer gets called… It appears that if the the access violation makes it way into some managed unwind logic, things end up stuck there and eventually, the app just aborts… never calling any unhandled exception filters. This seems somewhat specific to access violation. I have tried “RaiseException” with other values and things seem ok. In addition, if normal std::exceptions seem fine as well.

ConsoleTestApplication.zip

Reproduction Steps

I have attached a zip file that contains a solution with projects and code necessary to replicate what we are seeing in our much larger application. To replicate using the attached please do the following:

• Open ConsoleTestApplication.sln in Visual Studio 2022
• Build the solution.
• Run the resulting consoletestapplication.exe.

Expected behavior

when running the resulting executable, you should see the following Message Box appear:

Actual behavior

Instead, what happens is this output in the console

Testing unhandled exceptions in netcore!
Generationg System Access violation by Win32 RaiseException API.
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 . CLRInterop.makeException()

at .? A0xd840671c.managedTestFunc()

ConsoleTestApplication.exe (process 9288) exited with code -1073741819.

Regression?

This worked as of .netframrework 4.8

Known Workarounds

No response

Configuration

.net7 and .net8 on Windows x64

Other information

No response

[jkotas]

Access violations are symptoms of corrupted process state, and they are not catchable in .NET Core/5+.

Why do you need to catch access violations?

[awbushnell]

Access violations are symptoms of corrupted process state, and they are not catchable in .NET Core/5+.

Why do you need to catch access violations?

@jkotas In this case we are not attempting to catch but rather we have a native unhandled exception filter that is setup so we can do some data collection etc. then shutdown. The issue in this particular case is that the code flow goes something like :

Native -> managed -> native and in the lower native layer is where structured exception occurs... and once it winds back to managed all is lost and our filter does not get called..

[jkotas]

#79706 (comment) is a discussion about exposing a new API to allows installing a custom (unmanaged) handler for fatal errors like access violations that are symptoms of unrecoverable process state corruption.

Would that work for you?

[awbushnell]

#79706 (comment) is a discussion about exposing a new API to allows installing a custom (unmanaged) handler for fatal errors like access violations that are symptoms of unrecoverable process state corruption.

Would that work for you?

@jkotas If I understand that properly, it essentially is a call back mechanism to get control before the fatal termination? If I follow that properly, then yes, that seems it would help us in this case.

[jkotas]

Yes, that's correct. Do you have an opinion about what the signature of the callback should be?

[awbushnell]

Yes, that's correct. Do you have an opinion about what the signature of the callback should be?

@jkotas Off top of my head, if the callback we registered were similar to what one registers for the Win32 Unhandled Exception filter, that would probably work best for us. But haven't given too much thought overall.

[cwensley]

We have a Mac and Windows desktop C/C++ application and would like have this implemented too so we can continue to use our custom crash reporting logic. On Mac we are able to override the signal handlers to do this, but there's no such facility on Windows.

Ideally this would be called from EEPolicy::HandleFatalError or equivalent so we can at least get the PEXCEPTION_POINTERS parameter to report all of the same relevant information.

We are investigating the use of AddVectoredExceptionHandler to catch these cases, which appears to work for stack overflows and access denied, but not uncaught exceptions .NET threads.

[jkotas]

cc @VSadov

[jkotas]

Superseded by #101560