Skip to content

AccessViolationException when moved to .NET 10 #122016

Description

@DoctorKrolic

Description

When moved from .NET 8 to .NET 10 we observed unusual crashes of our app due to AccessViolationException sometimes thrown from an interop library code. Our first guess was that library itself, but we were able to somewhat isolate the problem and now we have evidence, that the runtime upgrade is the reson

Reproduction Steps

Project file:

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

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0-windows</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Vanara.PInvoke.FwpUClnt" Version="4.2.1" />
  </ItemGroup>

</Project>

Program.cs:

using System.Runtime.CompilerServices;
using Vanara.InteropServices;
using Vanara.PInvoke;
using static Vanara.PInvoke.FwpUClnt;

internal class Program
{
    private static void Main()
    {
        _ = FwpmEngineOpen0(serverName: null, Rpc.RPC_C_AUTHN.RPC_C_AUTHN_WINNT, authIdentity: IntPtr.Zero, (SafeCoTaskMemStruct<FWPM_SESSION0>)new FWPM_SESSION0(), out var sessionHandle);
        while (true)
        {
            _ = HasPermanentFilters(sessionHandle);
        }
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    public static bool HasPermanentFilters(SafeHFWPENG sessionHandle)
    {
        var result = FwpmFilterEnum0(sessionHandle, out var filters);
        result.ThrowIfFailed();

        foreach (var filter in filters)
        {
            if (filter.subLayerKey == Guid.Empty)
            {
                return true;
            }
        }

        return false;
    }
}

Apologies for repro with external library code, this is the most where we can get by ourselves

Expected behavior

App runs indefinetly

Actual behavior

Crash with access violation after some time. If I change target framework to net9.0-windows or net8.0-windows the problem disappears

Regression?

Yes, regression in .NET 10

Known Workarounds

No response

Configuration

Windows 10, x64

Other information

This only repros in Release mode, which also suggests that runtime bug is the reason for crash

Activity

  1. added
    needs-area-labelAn area label is needed to ensure this gets routed to the appropriate area owners
    on Nov 27, 2025
  2. MihaZupan commented on Nov 27, 2025

    @MihaZupan
    Member

    dahall/Vanara#565 looks related

  3. DoctorKrolic commented on Nov 27, 2025

    @DoctorKrolic
    ContributorAuthor

    @MihaZupan yes, this is the issue, that was reported on Vanara side. My colleague commented there as well. However, there is a suspicion, that bug lies in the runtime. At least, the issue doesn't repro on .NET 8 or 9 and on .NET 10 only in release mode

  4. jkotas commented on Nov 27, 2025

    @jkotas
    Member

    The repro fails for me with:

    Unhandled exception. System.UnauthorizedAccessException: Access is denied. (0x80070005 (E_ACCESSDENIED))
       at Program.HasPermanentFilters(SafeHFWPENG sessionHandle) in C:\repro\Program.cs:line 21
       at Program.Main() in C:\repro\Program.cs:line 13
    

    Crash with access violation after some time

    How long does it usually take to crash?

    Could you please enable crash dumps by following https://learn.microsoft.com/en-us/dotnet/core/diagnostics/collect-dumps-crash, and then share the crash dump with us here, or by opening an issue at https://developercommunity.visualstudio.com/ and attaching the crashdump as a private attachment. (The crash dump contains private information like your local user name and environment.)

  5. added
    needs-author-actionAn issue or pull request that requires more info or actions from the author.
    on Nov 27, 2025
  6. DoctorKrolic commented on Nov 27, 2025

    @DoctorKrolic
    ContributorAuthor

    @jkotas Oh, I forgot to mention that the repro uses Windows Filtering Platform APIs, that require elevated access. I just setuped my Visual Studio shortcut at work to open it as admin, so I forgot that detail. If you don't trust the input, run it in isolated environment. Although I don't see reasons to: the library is open source, that particular version has been published for quite some time now and I am not an account registered yesterday)

    I also just tested this repro on my howme PC with Windows 11 24H2. Fully reproduced the issue: infinite loop on .NET 8/9 and crash after some time on .NET 10

    How long does it usually take to crash?

    Here at home it took about 3-10 seconds. At work it seemed to happen more quickly

  7. jkotas commented on Nov 27, 2025

    @jkotas
    Member

    It is crashing under Marshal.PtrToStructure:

    System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
       at System.SpanHelpers.IndexOfNullCharacter(Char*)
       at System.Runtime.InteropServices.Marshal.PtrToStructure(IntPtr, System.Type)
       at Vanara.Extensions.InteropExtensions.ToStructure(IntPtr, System.Type, Vanara.PInvoke.SizeT, Vanara.PInvoke.SizeT, Int32 ByRef)
       at Program.HasPermanentFilters(SafeHFWPENG)
       at Program.Main()
    

    Marshal.PtrToStructure is called on what seems to be partially uninitialized memory here. You may or may not get a crash depending on the content of the uninitialized memory. The crash above is caused by trying to marshal a pointer as a string - but the pointer is not pointing to a zero terminated C string.

    This looks like a problem in the Vanara package to me.

  8. DoctorKrolic commented on Nov 27, 2025

    @DoctorKrolic
    ContributorAuthor

    This looks like a problem in the Vanara package to me.

    Why does it only repros on .NET 10 and not 8 or 9, only in release mode and only after some time (which suggests that this is related to tired JITting) then? Too many suspicious facts

  9. jkotas commented on Nov 27, 2025

    @jkotas
    Member

    It is not unusual for interop crashes to be triggered by unrelated conditions.

    There is certainly non-zero chance that there this is a bug in the runtime. What I have seen for far points at a bug in the Vanara package or a bug in how the Vanara package is used.

  10. jkotas commented on Nov 27, 2025

    @jkotas
    Member

    I do not see logic in the native memory enumerators in the Vanara package to keep the objects wrapping the native memory alive while the memory is being enumerated. The object wrapping the native memory may be garbage collected and free the native memory in its finalizer while the native memory is still being used.

    You can try workaround it by adding some GC.KeepAlives - I do not see the crash anymore with this change:

        [MethodImpl(MethodImplOptions.NoInlining)]
        public static bool HasPermanentFilters(SafeHFWPENG sessionHandle)
        {
            var result = FwpmFilterEnum0(sessionHandle, out var filters);
            result.ThrowIfFailed();
    
            foreach (var filter in filters)
            {
                if (filter.subLayerKey == Guid.Empty)
                {
                    return true;
                }
            }
    
            GC.KeepAlive(result);
            GC.KeepAlive(filters);
    
            return false;
        }
    
  11. added
    tracking-external-issueThe issue is caused by external problem (e.g. OS) - nothing we can do to fix it directly
    on Nov 27, 2025
  12. DoctorKrolic commented on Dec 3, 2025

    @DoctorKrolic
    ContributorAuthor

    The issue has been fixed on Vanara side, closing as dupe.

    @jkotas Special thank you for taking time to investigate this bug!

  13. locked and limited conversation to collaborators on Jan 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    • Status
      No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions