Access Violation starting with .NET 8.0.0 when debugging console application with Visual Studio on Windows x64

[kpreisser]

Description

Hi, I noticed that after upgrading from .NET 7.0.14 to 8.0.0, debugging the following simple console application on Windows x64 with Visual Studio 17.8.3 causes an access violation, when setting a break point at the client.Connect(...) line, and then stepping over with F10.

However, this seems to happen only when debugging, so maybe it's a debugger-related issue only.

Reproduction Steps

Create the following two files:

• TestProject.csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <OutputType>Exe</OutputType>
    <Nullable>enable</Nullable>
  </PropertyGroup>

</Project>

• Program.cs

using System.Net.Sockets;
using System.Threading;

class Program
{
    private static readonly string serverName = "localhost";
    private static readonly int serverPort = 12345;

    private static long x;
    private static long y;

    static void Main()
    {
        var updateConsoleThread = new Thread(() =>
        {
            long localX = x;
            long localY = y;
        });

        updateConsoleThread.Start();

        var senderThread = new Thread(() => RunSenderThread());
        senderThread.Start();

        senderThread.Join();
        updateConsoleThread.Join();
    }

    private static void RunSenderThread()
    {
        using var client = new TcpClient();

        try
        {
            client.Connect(serverName, serverPort);
        }
        catch (SocketException)
        {
            // Ignore
        }
    }
}

• Open the project in Visual Studio 2022 Version 17.8.3.
• Set a breakpoint at the client.Connect(serverName, serverPort); line:
  
• Start debugging with F5.
• Notice that the breakpoint is reached normally:
  
• Now try to continue by pressing F10 (Step-Over).
• Instead of continuing, an access violation occurs in most of the cases:

The program '[6492] TestProject.exe' has exited with code 3221225477 (0xc0000005) 'Access violation'.

Video

This video shows the reproduction steps I used on an empty Windows Server 2022 VM (Build 20348.2113). Note that the first time running the application, the AV doesn't happen but an unexpected ArgumentOutOfRangeException occurs (which suggests an out-of-range port number would be specified). When trying again, the AV occurs.

Repro-Dotnet-Runtime-Issue-96322.mp4

Expected behavior

No access violation occurs when pressing F10 after reaching the breakpoint.

Actual behavior

An access violation occurs in most cases when pressing F10 after reaching the breakpoint.

Regression?

Yes, this doesn't happen when running with .NET 7.0.14 instead of 8.0.0 (by changing the TargetFramework to net7.0).

Known Workarounds

No response

Configuration

• .NET 8.0.0, .NET SDK 8.0.100
• Visual Studio 17.8.3
• Windows 10 Version 22H2, x64 (Build 19045.3803)

Other information

No response

[ghost]

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

Issue Details

---

Description

Hi, I noticed that after upgrading from .NET 7.0.14 to 8.0.0, debugging the following simple console application on Windows x64 with Visual Studio 17.8.3 causes an access violation, when setting a break point at the client.Connect(...) line, and then stepping over with F10.

However, this seems to happen only when debugging, so maybe it is an issue in the debugger only.

Reproduction Steps

Create the following two files:

• TestProject.csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <OutputType>Exe</OutputType>
    <Nullable>enable</Nullable>
  </PropertyGroup>

</Project>

• Program.cs

using System.Net.Sockets;
using System.Threading;

class Program
{
    private static readonly string serverName = "localhost";
    private static readonly int serverPort = 12345;

    private static long x;
    private static long y;

    static void Main()
    {
        var updateConsoleThread = new Thread(() =>
        {
            long localX = x;
            long localY = y;
        });

        updateConsoleThread.Start();

        var senderThread = new Thread(() => RunSenderThread());
        senderThread.Start();

        senderThread.Join();
        updateConsoleThread.Join();
    }

    private static void RunSenderThread()
    {
        using var client = new TcpClient();

        try
        {
            client.Connect(serverName, serverPort);
        }
        catch (SocketException)
        {
            // Ignore
        }
    }
}

• Open the project in Visual Studio 2022 Version 17.8.3.
• Set a breakpoint at the client.Connect(serverName, serverPort); line:
  
• Start debugging with F5.
• Notice that the breakpoint is reached normally:
  
• Now try to continue by pressing F10 (Step-Over).
• Instead of continuing, an access violation occurs in most of the cases:

The program '[6492] TestProject.exe' has exited with code 3221225477 (0xc0000005) 'Access violation'.

Expected behavior

No access violation occurs when pressing F10 after reaching the breakpoint.

Actual behavior

An access violation occurs in most cases when pressing F10 after reaching the breakpoint.

Regression?

Yes, this doesn't happen when running with .NET 7.0.14 instead of 8.0.0 (by changing the TargetFramework to net7.0).

Known Workarounds

No response

Configuration

• .NET 8.0.0, .NET SDK 8.0.100
• Visual Studio 17.8.3
• Windows 10 Version 22H2, x64 (Build 19045.3803)

Other information

No response

Author:	kpreisser
Assignees:	-
Labels:	area-Diagnostics-coreclr, untriaged, needs-area-label
Milestone:	-

[Fabi]

Hmm. tested it 10 times (on mac and windows) and I always reach the SocketException

[kpreisser]

Hi @Fabi,
thanks for your reply! On which hardware platform on Windows did you test this? I could reproduce the AV on two different physical machines (both running Windows 10 Version 22H2 x64 on different Intel Core i5/i7 CPUs, with Visual Studio 2022 Version 17.8.3).

Additionally, I have now uploaded a video (in the original post) showing the reproduction steps on a clean Windows Server 2022 VM (Build 20348.2113), hope this helps! Thanks!

[Fabi]

Hmm. Im on latest Win11 & macOS. But I'm already confused by your first port related exception :D

[tommcdon]

Regression caused by #96339

[tommcdon]

Hi @kpreisser, would you mind try setting DOTNET_EnableAVX=0? That would help to confirm my suspicion that the issue is caused by #96339.

[danmoseley]

@tommcdon is that the right ID?

[kpreisser]

Hi @tommcdon,
thanks for your reply!

I tried setting the DOTNET_EnableAVX environment variable to 0 (using the Launch Profiles dialog), but it doesn't seem to make any difference; the Access Violation still happens when debugging with the set breakpoint. I modified the code to verify the variable is correctly set:

    private static void RunSenderThread()
    {
        using var client = new TcpClient();

        try
        {
            Debug.WriteLine($"DOTNET_EnableAVX: '{Environment.GetEnvironmentVariable("DOTNET_EnableAVX")}'");
            client.Connect(serverName, serverPort);
        }
        catch (SocketException)
        {
            // Ignore
        }
    }

However, when debugging with the breakpoint and then continuing, the AV still happens:

DOTNET_EnableAVX: '0'
'TestProject.exe' (CoreCLR: clrhost): Loaded 'C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\PrivateAssemblies\Runtime\Microsoft.VisualStudio.Debugger.Runtime.NetCoreApp.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'TestProject.exe' (CoreCLR: clrhost): Loaded 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.0\netstandard.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
The program '[19592] TestProject.exe' has exited with code 3221225477 (0xc0000005) 'Access violation'.

Thanks!

[tommcdon]

@tommcdon is that the right ID?

The ID was indeed incorrect. The correct PR that caused the regression is #89705

[tommcdon]

@kpreisser I have found the source of the regression and have a candidate fix: #96352. The issue is that we are not skipping AMD64 instruction prefixes and are treating the prefix as the opcode when single-stepping over the breakpoint patch table. I can provide a private 8.0 build for testing purposes. Please let me know if you would be willing to try it out to help verify the fix.

[kpreisser]

Hi @tommcdon,
thank you! Yes, I would be willing to try out the 8.0 test build.

[tommcdon]

Hi @kpreisser! Please unzip the 5 DLL's from https://github.com/tommcdon/runtime/releases/tag/8.0_x64_stepping_fix and copy them into your .NET 8 install directory (e.g. %ProgramFiles%\dotnet\shared\Microsoft.NETCore.App\8.0.0) and back up the original files. Note .NET Runtime Debugger library signature checks will need to be disabled as well: https://aka.ms/vs/unsigned-dotnet-debugger-lib.

[kpreisser]

Hi @tommcdon,
thanks for fixing the issue and providing the test binaries! I can confirm that with using these binaries, I'm no longer able to reproduce the access violation.

[tommcdon]

Servicing approved the 8.0 backport PR, so closing this issue