While rigging up a view model with the
PropertyChangedEventManager, I got a crash bug in my event handler that crashed my unit test and took out the .NET CLR on the way down.
It produced this frightening-sounding exception:
Managed Debugging Assistant 'FatalExecutionEngineError' has detected a problem in 'C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 12.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\vstest.executionengine.x86.exe'. Additional information: The runtime has encountered a fatal error. The address of the error was at 0x6c99e4ad, on thread 0x23e4. The error code is 0x80131623. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.
So I went and took a look in the event viewer after following a link that said that 0x80131623 would produce an error there. That’s where I found this also scary but much more informative error thrown in WindowsBase:
Application: vstest.executionengine.x86.exe Framework Version: v4.0.30319 Description: The application requested process termination through System.Environment.FailFast(string message). Message: Unrecoverable system error. Stack: at System.Environment.FailFast(System.String) at MS.Internal.Invariant.FailFast(System.String, System.String) at System.Windows.WeakEventManager+ListenerList.DeliverEvent(Listener ByRef, System.Object, System.EventArgs, System.Type) ...
Okay, so why does
FailFast get triggered? It turns out that
FailFast is effectively the same thing as a CLR-crashing assert, so something has asserted inside the .NET CLR.
A bit more searching and I found out that the cause is that I had returned
false from my
ReceiveWeakEvent method. The reasoning as per the CLR code is that an event handler that signed up explicitly to handle an event should handle the event. I guess I can’t argue with that.
The long and the short? Returning
true from my event handler made this crash bug go away.