FailFast exception when reflecting over wpf properties

• .NET Core Version: 5.0+
• Windows version: Windows 11
• Does the bug reproduce also in WPF for .NET Framework 4.8?: Yes
• Is this bug related specifically to tooling in Visual Studio (e.g. XAML Designer, Code editing, etc…)? No

Problem description: Copied from: https://developercommunity.visualstudio.com/t/Debug-session-crashes-when-expanding-a-B/1575407

This code demonstrates what happens when inspecting properties under the debugger. The target process crashes on the user.

public class Test : Control
{
    public override void OnApplyTemplate()
    {
        base.OnApplyTemplate();

        var be = GetBindingExpression(DataContextProperty);
        var p = be.GetType().GetProperty("DynamicConverter", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance);
        p.GetValue(be); // throws FailFast

    }
}

Actual behavior:

WindowsBase.dll!MS.Internal.Invariant.FailFast(string message, string detailMessage) Line 213 C# WindowsBase.dll!MS.Internal.Invariant.Assert(bool condition) Line 91 C# PresentationFramework.dll!System.Windows.Data.BindingExpression.DynamicConverter.get() Line 493 C#

Expected behavior: No Crash

[miloush]

There is thousands of Invariant.Assert calls through the codebase and I thought that crashing is a security precaution (as in my process cannot be trusted anymore, better not touch a thing).

The documentation for FailFast says:

Calling the Environment.FailFast method to terminate execution of an application running in the Visual Studio debugger throws an ExecutionEngineException and automatically triggers the fatalExecutionEngineError managed debugging assistant (MDA).

Is that information outdated?

[tommcdon]

Hello @miloush!

If I understand correctly you are saying the debugger has changed to no longer handle this scenario and instead of improving the debugger, you would go around all frameworks and applications and request them to accommodate?

The debugger has always treated ExecutionEngineExceptions as a corrupting exception. The only difference with .NET Core is that we do not fire a Managed Debug Assistant for this type of Exception. Otherwise the behavior is identical and the workaround I suggested still applies to both .NET Framework and .NET Core.

If you want fail fast only if the debugger is attached, then I think this should be done in the runtime rather than in WPF specifically

ExecutionEngineException is also used for other failures, such as access violations. Because of this, it is not safe to allow execution of managed code. My suggestion is that WPF changes its code to not trigger an ExecutionEngineException while the debugger is attached for internal retail assert failures.