Repository navigation
AccessViolationException when moved to .NET 10 #122016
Description
Activity
- addeduntriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner
on Nov 27, 2025 - addedneeds-area-labelAn area label is needed to ensure this gets routed to the appropriate area ownersAn area label is needed to ensure this gets routed to the appropriate area owners
on Nov 27, 2025 - added and removedneeds-area-labelAn area label is needed to ensure this gets routed to the appropriate area ownersAn area label is needed to ensure this gets routed to the appropriate area owners
on Nov 27, 2025 dahall/Vanara#565 looks related
@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
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 13Crash 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.)
- addedneeds-author-actionAn issue or pull request that requires more info or actions from the author.An issue or pull request that requires more info or actions from the author.
on Nov 27, 2025 @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
- removedneeds-author-actionAn issue or pull request that requires more info or actions from the author.An issue or pull request that requires more info or actions from the author.
on Nov 27, 2025 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.PtrToStructureis 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.
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
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.
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; }Reacted by Egor Bogatov, Andrii Kurdiumov, rampaa and AlexeyRusakovich- addedtracking-external-issueThe issue is caused by external problem (e.g. OS) - nothing we can do to fix it directlyThe issue is caused by external problem (e.g. OS) - nothing we can do to fix it directly
on Nov 27, 2025 The issue has been fixed on Vanara side, closing as dupe.
@jkotas Special thank you for taking time to investigate this bug!
- removeduntriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner
on Dec 3, 2025 - locked and limited conversation to collaborators
on Jan 2, 2026
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsNo status
Description
When moved from .NET 8 to .NET 10 we observed unusual crashes of our app due to
AccessViolationExceptionsometimes 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 resonReproduction Steps
Project file:
Program.cs: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-windowsornet8.0-windowsthe problem disappearsRegression?
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