Some exceptions cannot be caught by a try/catch block or global exception handler

[pweerd]

Describe the bug

Following code is causing an Exception that cannot be caught:

      try {
         char* p = (char*)0x100000000L;
         *p = ' ';
      } catch (Exception err) {
         MessageBox.Show (null, err.Message, "Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
      }

If this code is executed, the application silently terminates.

This is a major problem, since I'mwriting a text editor, where:

• I cannot offer my users a way to quickly safe their work
• I cannot inform my user what happened
• I cannot log the error, which makes it much harder to diagnose. Especially when the user is remote.
  There is only a message in the eventlog. And there might be a WER report. Both give not enough information to do a post mortem a diagnose.

To Reproduce

Please have a look at https://github.com/pweerd/ExceptionBug.
You can press the 2nd button, which should be caught by the unhandled exception handler, or press the 3rd button, which should be caught be its own try/catch block.

Exceptions (if any)

The example causes a System.AccessViolationException

Further technical details

My dotnet runtime info:

.NET SDK (reflecting any global.json):
 Version:   6.0.200
 Commit:    4c30de7899

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19044
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.200\

Host (useful for support):
  Version: 6.0.2
  Commit:  839cdfb0ec

.NET SDKs installed:
  6.0.200 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.14 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.14 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 5.0.14 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download```

[pweerd]

I am coming from .Net3.5... In that version the try/catch is simply working

[KalleOlaviNiemitalo]

The invalid pointer would cause a corrupted process state exception… and .NET Core ignores HandleProcessCorruptedStateExceptionsAttribute.

What you can do is

• autosave often, before the exception is thrown
• isolate unreliable code to a separate process

I don't think you can reliably use RegisterApplicationRecoveryCallback with a recovery callback implemented in managed code.

[pweerd]

OK, Its a feature, not a bug :-(
I've read some background about the why of the decision to simply crash the application...

So, after a GPF we feel that the CLR is not stable enough. And to prevent possible data corruption, we crash the application. Seriously? What did we win here? Now its a guarantee that there is data loss!

NB: my original problem was a GPF during a read operation. And that was already enough to crash the application.
Did we do any statistics about how often there is data corruption after catching a GPF?

I strongly disagree with this reasoning about corruptness. I've never, ever, seen a problem with catching GPF exceptions. And I've seen a few data losses because of application crashes. Admitted: this is no good stats, but my intuition is that by making it impossible to catch these exceptions, we create bigger problems.
Also, as a programmer, I don't want other people to make decisions for me. Where does this stop? Cancel the 'unsafe' feature as well? Its very dangerous!!! Oh, and what about reflection?

OK, I stop being frustrated...
Can you please, please, reconsider this thinking? Having an option to escape from this nightmare would be great!

[jhudsoncedaron]

@pweerd : So, I do have something to say here.

The one that gets on my nerves the most is the fact that StackOverflowException can't be caught. But I feel your pain. It is quite likely that recovering from a native wild pointer is impossible but I would rather have the option to try. The last time I was able to catch one that wasn't a null, new didn't work after so that catch block is very hard to write.

Oh, and a wild read can corrupt your process. Here is one reason: #45971 but also I think fixing that won't remove all the causes because the GC uses guard pages too

In any case this issue probably needs to get moved to runtime.

I don't think you can reliably use RegisterApplicationRecoveryCallback with a recovery callback implemented in managed code.

That's correct. The constrained execution attributes don't work either.

[jkotas]

#101560 is introducing a low-level callback that will allow customizing .NET runtime fatal error handling, e.g. logging additional information or restarting the process. However, it won't allow ignoring the fatal error and continuing execution of the current process.

.NET runtime treats access violations as fatal errors. It terminates process immediately for (dirty) access violations. It is done for security reasons. We are not interested in changing this behavior or making it configurable. Dirty access violation should not happen in correct programs and they are symptom of a security bug like a buffer overrun.

I've never, ever, seen a problem with catching GPF exceptions.

FWIW, we have seen many problems with catching GPF exceptions, and we have spent a lot of time on analyzing .NET Framework crashes that were eventually back tracked to a GPF exception caught and ignored earlier.