NullReferenceException from MetaDataGetDispenser

[Camios]

Description

Stack trace
0 {"assembly":"KERNELBASE.dll","method":"RaiseException","level":0,"line":0}
1 {"assembly":"coreclr.dll","method":"MetaDataGetDispenser","level":1,"line":0}
2 {"assembly":"coreclr.dll","method":"0x7ffa42e90d36","level":2,"line":0}
3 {"assembly":"ntdll.dll","method":"RtlDeleteAtomFromAtomTable","level":3,"line":0}
4 {"assembly":"ntdll.dll","method":"RtlRaiseExceptionForReturnAddressHijack","level":4,"line":0}
5 {"assembly":"ntdll.dll","method":"KiUserInvertedFunctionTable","level":5,"line":0}
6 (our code which is a WPF UserControl Unloaded event handler that unhooks events from the System.Windows.Application and from the hosting System.Windows.Window)

Reproduction Steps

Random and very few cases

Given the unexpected call site for a NullReferenceException, some colleagues are suspicious of the stack trace.
If the stack trace is wrong, then that is the "bug".
If the stack trace is right, then we couldn't find much about KiUserInvertedFunctionTable or the other methods. we have two potential theories:

1. There is a bug in clr code; or

2. Because we're in an unloaded event handler (possibly because the app is exiting) and we are unhooking events, could the Application or Window be "dead" from the clr's perspective and we shouldn't be trying to unhook the events?

    private void UserControl_Unloaded(object sender, RoutedEventArgs e)
    {
    	ViewModel.Shutdown();
   
    	// Not sure about the reason for storing Application.Current in a local var - is there a possible race - can Application.Current become null from another thread while we are in this method? 
    	// And if Application's reference to Current is null, should we still be unhooking events?
    	if (Application.Current is Application application)
    	{
    		application.Deactivated -= Application_Deactivated;
    	}
   
    	m_service.Added -= Service_Changed;
    	m_service.Updated -=Service_Changed;
   
    	m_window.Activated -= Window_Activated;
    	m_window.LocationChanged -= Window_LocationChanged;
    	m_window.SizeChanged -= Window_SizeChanged;
    	m_window.Closing -= Window_Closing;
    	m_window = null;
    }
   

Expected behavior

NullReferenceException from coreclr code

Actual behavior

Depends on the cause: If a bug in clrcode, then a fix in .net 8 would be great.
If the bug is in our code, we'd appreciate an explanation/advice to fix our code, please.

Regression?

No response

Known Workarounds

No response

Configuration

.NET 8.0.7
Microsoft Windows NT 10.0.19045.0
AMD Ryzen Threadripper PRO 5975WX
128GB RAM

Other information

No response

[jkotas]

some colleagues are suspicious of the stack trace.

Yes, the stacktrace is wrong. You will get stacktrace like this with missing symbols for native code.

You can use https://learn.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-symbol tool to download the symbols for coreclr.dll and then point the tool that you have used to generate the stacktrace to use the download symbols.

[Camios]

How wrong can the stack trace be? Are the stack frame methods completely wrong i.e. it is not MetaDataGetDispenser?
Or is it just missing extra info (like source file path and line numbers)?

BTW The stack trace is from Azure telemetry (it's not a crash dump), but someone's looking at using a symbol server at the time of the exception/crash.

[jkotas]

Are the stack frame methods completely wrong i.e. it is not MetaDataGetDispenser?

Right, the stack frame methods are completely wrong. MetaDataGetDispenser is one of the few methods exported from coreclr.dll and it tends to get picked up as the fallback symbol name when there are no full symbols available.

Azure telemetry

Could you please tell us more about the Azure telemetry that's producing these wrong symbols? The issue should be reported to them.