ANCM In process: Managed exceptions before full initialization are too hard to look at

[davidfowl]

Epic #8833

While testing out the generic host with the new ValidateOnBuild feature (which fails to build the host if there's an issue with services), I noticed that its really hard (even in development) to just get access to the managed exception when using ANCM in proc. If there's an exception in Program.cs, this is what you see:

Then the event log shows this:

This is a pretty bad experience for looking at a simple managed exception. Here are the steps we advertise to troubleshoot:

Troubleshooting steps:
- Check the system event log for error messages
- Enable logging the application process' stdout messages
- Attach a debugger to the application process and inspect

• The event log tells me there's a manged exception, but nothing more.
• Enabling stdout logging means I suddenly need a web.config file. Do we have a tooling gesture to turn this on? When I add a web.config it gives me this:

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
  
    <!-- To customize the asp.net core module uncomment and edit the following section. 
    For more info see https://go.microsoft.com/fwlink/?linkid=838655 -->
    <!--
    <system.webServer>
      <handlers>
        <remove name="aspNetCore"/>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified"/>
      </handlers>
      <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
    </system.webServer>
    -->
  
  </configuration>

  Which I am assuming isn't correct for inproc hosting.
• The default debugger settings don't break when this exception occurs. The output window does show this obscure message though:

  Exception thrown: 'System.InvalidOperationException' in Microsoft.Extensions.DependencyInjection.dll
  Exception thrown: 'System.InvalidOperationException' in Microsoft.Extensions.DependencyInjection.dll
  Exception thrown: 'System.AggregateException' in Microsoft.Extensions.DependencyInjection.dll
  

• Changing the debugger settings to break on all exceptions does work.

We need to improve this. Here are some things I can think of:

• We should re-think replacing the built in exception handler for .NET or finding a way to call into it when an unhandled exception happens. It logs the exception information to the event log with all of the details. Here's an example:
  
• We should show an error page with the exception in development.
• We could potentially make our own managed entry point that we call into first in order to set things up such that we can get unhandled exceptions and handle them appropriately. Something like the following:

public static void HookExceptionHandler()
{
    AppDomain.CurrentDomain.UnhandledException += (sender, e) =>
    {
        if (e.IsTerminating)
        {
            // Log to the event log here
        }
    };
}

We would call this delegate first (it would exist in the IIS integration assembly) so that before we called into main, we'd have logic in managed code to hook up the unhandled exception event handler.

[pakrym]

We should re-think replacing the built in exception handler for .NET or finding a way to call into it when an unhandled exception happens. It logs the exception information to the event log with all of the details.

https://github.com/dotnet/core-setup/issues/4836

[davidfowl]

That doesn’t solve all of the issues with the experience but it’s a start 😬.

[muratg]

@davidfowl core-setup issue is in "Future" milestone.

[davidfowl]

It's going to be in 3.0

[analogrelay]

Started exploring here: #8518
Blocked on dotnet/coreclr#23054 (which is now merged, so we might be unblocked ;))

[pakrym]

It's not blocked on that, it's blocked on implementing setting runtime options by hosting process dotnet/core-setup#5486

[jkotalik]

Specifically it is blocked on setting the startup hook. There should be an environment variable though that we can set for now to verify.

[jkotalik]

This is done. #9520 is the only follow up issue I can think of.

(I'm still going to do verification in the E2E).