AppDomain.UnhandledException not triggered when running under custom .NET Host

[Tyrrrz]

Hi!

I have my own custom .NET runtime host built on top of legacy .NET framework. I'm able to run the target .NET Core app just fine.

However, I have encountered a problem where if the target app subscribes to AppDomain.CurrentDomain.UnhandledException and crashes with an unhandled exception, then the event is not triggered. The event is triggered as expected when running using default exe apphost or from .NET CLI.

Here's the code that wraps hostfxr.dll:

https://github.com/Tyrrrz/DotnetRuntimeBootstrapper/blob/8d07097dbb1751a2322132ff1229cdbf7be4d45f/DotnetRuntimeBootstrapper.AppHost/Dotnet/DotnetHost.cs#L60-L125

Here's the implementation of NativeLibrary.GetFunction():

https://github.com/Tyrrrz/DotnetRuntimeBootstrapper/blob/8d07097dbb1751a2322132ff1229cdbf7be4d45f/DotnetRuntimeBootstrapper.AppHost/Native/NativeLibrary.cs?_pjax=%23js-repo-pjax-container%2C%20div%5Bitemtype%3D%22http%3A%2F%2Fschema.org%2FSoftwareSourceCode%22%5D%20main%2C%20%5Bdata-pjax-container%5D#L17-L30

Closing the host context returns 0. As mentioned, everything else works fine besides that event handler.

Hostfxr used: C:\Program Files\dotnet\host\fxr\6.0.0\hostfxr.dll

Related issue: Tyrrrz/DotnetRuntimeBootstrapper#27

Any suggestions as to what I might be doing wrong?

[jkotas]

Hosting .NET Framework and .NET Core in the same process is not fully supported. Some scenarios (in particular diagnostics, like debugging) are known to be broken.

I have encountered a problem where if the target app subscribes to AppDomain.CurrentDomain.UnhandledException and crashes with an unhandled exception

My guess is that .NET Framework exception handling takes over and does not propagate the unhandled exception to allow .NET Core to handle it.

[Tyrrrz]

Thanks for your reply.

My guess is that .NET Framework exception handling takes over and does not propagate the unhandled exception to allow .NET Core to handle it.

Is there any way for me to verify this? Would that mean that apphost's own (on .NET Framework's side) AppDomain.CurrentDomain.UnhandledException should trigger for unhandled exceptions inside the target .NET Core app? Because it doesn't seem like it does. All I get is SEHException thrown by hostfxr_run_app inside this catch block.

[Misiu]

@jkotas any ideas on how we can proceed with this? https://github.com/Tyrrrz/DotnetRuntimeBootstrapper is an awesome project and it would really benefit from the ability to handle that error.
Any help is more than welcome 🙂

[jkotas]

I understand the intent of the project. It is trying to move installation of dependencies that is typically done by the installers into the app itself.

It used dotnet CLI previously in a separate process

I have not suggested using dotnet CLI in a separate process. I have suggested launching the .NET Framework updater in a separate process.

[Tyrrrz]

I have not suggested using dotnet CLI in a separate process. I have suggested launching the .NET Framework updater in a separate process.

Then I must've misunderstood. Do you mean using a native executable for apphost purposes and a .NET framework app for installing dependencies?

[jkotas]

Yes.

[Tyrrrz]

Thanks for the suggestion.

As an aside, is there any way I can diagnose this issue to verify with certainty that it's indeed caused by .NET Framework somehow takes over exception handling? Also is there anywhere I can read about other scenarios you mentioned in "As I have said, there are known scenarios that do not work and that we do not plan to fix"? This is the only one I've encountered so far.

[jkotas]

I think you would need to use windbg to figure out what is exactly going on. Visual Studio does not work well when both .NET Framework and .NET Core are loaded in the same process.

#53729 and linked issues have more discussions about .NET Framework and .NET Core side-by-side in the same process.