.net core 2.1 AppDomain.CurrentDomain.UnhandledException

[jkotas]

From @zhaojie on November 26, 2018 6:20

.net core 2.1
To avoid program crash, I use AppDomain.CurrentDomain.UnhandledException to catch the unhandledexception，but the program still crashes and exits

Where to set this property of UnhandledExceptionEventArgs.IsTerminating ?

.net, can set this legacyUnhandledExceptionPolicy
<runtime> <legacyUnhandledExceptionPolicy enabled="true" /> </runtime>

but in .net core, hot to do?

Copied from original issue: dotnet/corefx#33689

[jkotas]

From @MarcoRossignoli on November 26, 2018 10:6

Seems not supported
https://github.com/dotnet/coreclr/blob/c94d8e68222d931d4bb1c4eb9a52b4b056e85f12/src/inc/clrconfigvalues.h#L778
https://github.com/dotnet/coreclr/blob/c4bf09d95011c0b4f86be1001b228b337a11fdd4/Documentation/project-docs/clr-configuration-knobs.md#L811
But comment says https://github.com/dotnet/coreclr/blob/c94d8e68222d931d4bb1c4eb9a52b4b056e85f12/src/inc/clrconfigvalues.h#L81 this value is available to partners/developers
I tried with https://github.com/dotnet/coreclr/blob/c4bf09d95011c0b4f86be1001b228b337a11fdd4/Documentation/building/viewing-jit-dumps.md#setting-configuration-variables with COMPlus_legacyUnhandledExceptionPolicy=1 and legacyUnhandledExceptionPolicy=1 but it doesn't work for me.

/cc @jkotas

[jkotas]

This is not supported in .NET Core (and it did not work reliably in .NET Framework for a while either). Unhandled exception will cause the program to be terminated.

Why do you need unhandled exceptions to be ignored?

[zhaojie]

@jkotas
I don't want the whole system to crash because of an unhandled exception，i can find out the problem from the AppDomain.CurrentDomain.UnhandledException.
have a plan to support it?

Finally, thank you.

[jkotas]

Back during .NET Framework 1.x, we have found that silently ignoring unhandled exceptions just leads to much worse reliability problems later as explained in https://docs.microsoft.com/en-us/dotnet/standard/threading/exceptions-in-managed-threads. We do not have plans to encourage or support silently ignoring unhandled exceptions.

cc @janvorli

[zhaojie]

OK, thank you.

[sergiy-k]

Is there anything actionable here or this issue can be closed?

[osexpert]

But what is the difference between adding try { } catch (Exception e) when (HandleException(e)) { // eat }
around all code in my app versus the clr doing the try\catch for me and calling the HandleException (aka. AppDomain.CurrentDomain.UnhandledException\IsTerminating) for me?
The former is reliable and the latter is unreliable? Why?
In practice, spreading try\catch around 100% of the code is impossible thou, and for apps supporting plugins it is impossible.

"We do not have plans to encourage or support silently ignoring unhandled exceptions"
He was asking for a way to prevent the process from terminating in case of unhanded exception. Not silently ignoring them.

[nxrighthere]

I've encountered this problem while working on the integration of hostfxr into the game engine which should run continuously during development. It operates with dynamically loaded assemblies via AssemblyLoadContext and as soon as any unhandled exception occurs in user assemblies, the .NET Core runtime terminating the entire process with the editor of the game engine which leads to loss of all unsaved resources. I would like to get control over this behavior and redirect the exception output using a custom native function to the editor's console window (similar to hostfxr_set_error_writer but for the exceptions), then stop the execution of the logic and immediately unload the assembly without terminating the editor.

Any suggestions?

[janvorli]

@nxrighthere I have a naïve question - do the dynamically loaded assemblies have some well defined interface so that you could catch all exceptions on it?

[nxrighthere]

Nope, but I can implement this. A perfect solution for me would be to handle this globally and transparently for the end-user without involving an additional code into dynamic assemblies.

[janvorli]

I think that you can make it work without end user being involved probably in majority of the cases, however if the end user code used e.g. threads, strong GC handles, RegisteredWaitHandles or if it registered an event handler to some event that lives outside of their code (e.g. System.Diagnostics.Process.Exited) , it would need to cooperate on the shutdown by registering AssemblyLoadContext.OnUnload handler and shutting the threads, closing the strong handles, unregistering events etc.

[janvorli]

Please see https://docs.microsoft.com/en-us/dotnet/standard/assembly/unloadability for all the details.

[nxrighthere]

@janvorli Yes, but how to prevent termination of the process that embeds hostfxr? According to this issue, we don't have an alternative to legacyUnhandledExceptionPolicy in .NET Core.

[janvorli]

My point was that if you can catch all the exception at the interface, there should not be any unhandled exceptions (other than access violations).

[nxrighthere]

Interesting, the process is still get terminated even if the code is wrapped with try/catch block:

try {
    throw new Exception("Test exception");
}

catch (Exception exception) {
    return;
}

The process was terminated due to an internal error in the .NET Runtime at IP 00007FFD813C66D9 (00007FFD81180000) with exit code 80131506.

[janvorli]

Are you saying that it behaves like this even in the simple block that looks exactly like what you've pasted above or is the throw somewhere in the code running inside of the unloadable context and the catch outside of it?

[nxrighthere]

Yes, it behaves like that exactly with this code. A dynamic assembly with a static function is loaded at runtime using AssemblyLoadContext.LoadFromAssemblyPath, then a pointer to it is obtained and passed to the native runtime and invoked from there. If there are no exceptions, then the code executes just fine.

[janvorli]

So the throw / catch is inside the loaded assembly, right? Does the problem happen also when running without debugging (when running from command line or when running from the VS using "Start without debugging")?

[nxrighthere]

So the throw / catch is inside the loaded assembly, right?

Yes. Exceptions in the parent assembly which was loaded using hostfxr_get_runtime_delegate with load_assembly_and_get_function_pointer from coreclr_delegates.h, are handled properly without any issues. Only in dynamically loaded assemblies, this error occurs.

Does the problem happen also when running without debugging (when running from command line or when running from the VS using "Start without debugging")?

Nope, it works as intended just like in the parent assembly of hostfxr.

[janvorli]

Ok, then it is a problem with debugger / debugger support code. It may be the same as #2317.

[nxrighthere]

Yes, I have the exact same problem. Thank you for pointing me to this issue.

[janvorli]

Closing as dup of #2317