Issues stepping through System.Runtime.CompilerServices.StaticsHelpers.GetGCStaticBase

[gregg-miskelly]

Description

In .NET 10, new IL static variable helpers were added. If the debugger attempts to step through these, the step becomes a go (managed-only behavior) or the step completes at an exception handler (interop debugging behavior).

Reproduction Steps

1. Create a new .NET 10 console application and paste the following code:

void MyFunction(Func<int, int> f)
{
    int result = f(1);
    Console.WriteLine(result);
}

MyFunction(x => x + 1); // breakpoint here

Console.WriteLine("Done. Press any key to continue.");
Console.ReadLine();

2. Set a breakpoint on the line specified
3. Disable Just My Code in Visual Studio
4. Launch the program under the debugger and wait for the breakpoint to be hit
5. Step in

Expected behavior

Step should land in 'MyFunction'

Actual behavior

When managed-only debugging: the step becomes a go

When interop debugging: Debugger breaks with this stack:

	ntdll.dll!ZwWaitForSingleObject() Line 268	Unknown
 	KernelBase.dll!WaitForSingleObjectEx(void * hHandle, unsigned long dwMilliseconds, int bAlertable) Line 1328	C
 	ntdll.dll!RtlpCallVectoredHandlers(_EXCEPTION_RECORD * ExceptionRecord, _CONTEXT * ContextRecord, unsigned long Index) Line 204	C
 	[Inline Frame] ntdll.dll!RtlCallVectoredExceptionHandlers(_EXCEPTION_RECORD *) Line 358	C
 	ntdll.dll!RtlDispatchException(_EXCEPTION_RECORD * ExceptionRecord, _CONTEXT * ContextRecord) Line 413	C
 	ntdll.dll!KiUserExceptionDispatch() Line 771	Unknown
 	[Managed to Native Transition]	
 	CsCon10.dll!Program.<Main>$(string[] args) Line 7	C#

If you look at the ExceptionRecord/ContextRecord, it is breaking at a STATUS_BREAKPOINT with this stack:

[0x0]   coreclr!CallDescrWorkerInternal+0x83   0xeacf57dff0   0x7ffa4a464b3c  
[0x1]   coreclr!DispatchCallDebuggerWrapper+0x1c   0xeacf57e030   0x7ffa4a464bf4  
[0x2]   coreclr!DispatchCallSimple+0x80   0xeacf57e080   0x7ffa4a464a9e  
[0x3]   coreclr!StressLog::InlinedStressLogOn+0x5   (Inline Function)   (Inline Function)  
[0x4]   coreclr!StressLog::StressLogOn+0x5   (Inline Function)   (Inline Function)  
[0x5]   coreclr!MethodTable::RunClassInitEx+0x11e   0xeacf57e110   0x7ffa4a465b33  
[0x6]   coreclr!MethodTable::DoRunClassInitThrowing+0x2f3   0xeacf57e1e0   0x7ffa4a46582f  
[0x7]   coreclr!MethodTable::CheckRunClassInitThrowing+0x27   (Inline Function)   (Inline Function)  
[0x8]   coreclr!InitClassHelper+0x5f   0xeacf57e770   0x7ffa47b0714f  
[0x9]   System_Private_CoreLib!System.Runtime.CompilerServices.InitHelpers.InitClassSlow+0x3f   0xeacf57e7b0   0x7ffa47b08908  
[0xa]   System_Private_CoreLib!System.Runtime.CompilerServices.StaticsHelpers.GetGCStaticBaseSlow+0x18   0xeacf57e880   0x7ff9ea9554e5  

Regression?

This is a regression from .NET 9

Known Workarounds

Enable Just My Code

Configuration

This is in .NET 10 preview 3 + x64 Windows. I didn't test other configurations.

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

[hoyosjs]

I couldn't repro this in P4

[hoyosjs]

Actually - it repros differently in VS and VSCode.

[steveisok]

I can repro in P4 and P5, but off of today's main I can't. Might be fixed. The mystery is by what commit or commits.

[hoyosjs]

This is a regression I believe from #108167.

A simpler repro:

private readonly static object s_param = new();

static void MyFunction(object param)
{
    Console.WriteLine(param);
}

static void Main(string[] args)
{
    MyFunction(s_param); // break and step in. 

    Console.WriteLine("Done. Press any key to continue.");
    Console.ReadLine();
}

[hoyosjs]

I can still repro on 4af81ca if I don't disable precompiled modules (i.e. SPC needs to be r2r). Once r2r is disabled, we get to some helpers that should be getting the same treatment as #106167

[hoyosjs]

Just so we don't lose track of what's been investigated - with @steveisok we've checked in this and turns out that this is now implemented via QCall. We try to step over the QCall, but there's also a breakpoint that ends up in the static constructor of the class. As we set the flag to avoid stepping into static construction, we try to step out and delete the patch to step over the QCall in the process.

[steveisok]

If we skip the frame stepping out of the static constructor, it fixes the issue. It's not yet clear exactly why things go haywire.