Environment.FailFast not capturing message and exception details to Windows Event Log

[alexwiese]

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

Microsoft .NET Core Shared Framework Host
Version : 2.0.0
Build : e8b8861

Repro

    private static void Main(string[] args)
    {
        Environment.FailFast("Something bad happened");
    }

On .NET Framework 4.6.1 the runtime creates the following event in the Application event log with the following details:

• Event ID: 1025
• Event source: .NET Runtime
• The message passed to FailFast (eg. "Something bad happened")

On .NET Core 2.0 no such event is logged. The only event is the generic windows Application Error (1000 event) which does not contain the stack trace or message passed to FailFast.

Has this been done for cross-platform reasons, ie. Unix has no Windows Event Log?
The event that gets logged on net461 is very useful and it would be good to have the same level of information on netcoreapp20.

[janvorli]

@jkotas I have briefly looked into it and it seems we have logging into event log disabled for CoreCLR. See the BOOL ShouldLogInEventLog(), it always returns FALSE for FEATURE_CORESYSTEM. Do you know if it is intentional?

[jkotas]

This was done for Windows Phone for some reason. I do not see a reason why it cannot be re-enabled for .NET Core.

Note that there are likely more changes required than just deleting this ifdef to make it work well. E.g. the if (pThread->GetDomain()->IsDefaultDomain()) path in DoReportForUnhandledException should be deleted. Ideally, everything around CrossAppDomainMarshaledException would be deleted too.

[lakeman]

Related problem, Environment.FailFast(System.String, System.Exception) is logging the message, but not the details of the exception.

This is making it impossible to diagnose the cause of my frequent restarts within IIS.

[danmoseley]

relevant: https://github.com/dotnet/coreclr/issues/9529

[danmoseley]

@sywhang were you planning to do this one also? It seems this would be very useful to some folks.

[danmoseley]

@lakeman

Related problem, Environment.FailFast(System.String, System.Exception) is logging the message, but not the details of the exception.

This sholud be fixed in 2.1

[sywhang]

Should be fixed with dotnet/coreclr#16875.

[Tadimsky]

@sywhang Is there any way we could get this fix ported to older versions? If it's in 2.1 and up we have to increase our min version for our app (which we are unable to do as we have to target RS1+)

[sywhang]

@Tadimsky what version of coreclr are you using?

[jkotas]

.NET Core 2.1 is expected to work on RS1+ fine.

[Tadimsky]

I think I may be confusing things then.
We're a .NET Native UWP app (which uses CoreCLR) - using the 1.7 version of the Tooling.

It looks like that UWP depends on CoreCLR >1.0.3? Is that correct?

[jkotas]

Right. .NET Native UWP is build from some of the same parts as .NET Core, but it is a different product with different versions, etc.

[Tadimsky]

@jkotas So if we are experiencing this issue with FailFast at the moment, how can we improve things? Since we can't update to newer versions of .NET Native Tooling if we want to support RS1.

[jkotas]

You should be getting data about your app crashes via https://docs.microsoft.com/en-us/windows/uwp/monetize/get-error-reporting-data . The Microsoft internal name for this is Watson.

[Tadimsky]

We're an internal app and use Watson. The data available in !analyze in WinDBG does not contain the information provided to FailFast due to this issue.
That's why I'm wondering if we can get this fix brought to older versions of CoreClr.

[jkotas]

I doubt that it is because of this issue. The logging added here goes to https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-reporteventw . This API is not allowed in UWP apps.