Access violation (0xC0000005, null-pointer read) in coreclr!ProcessCLRException at exceptionhandling.cpp:621 - reproducible 4/4, symbol-resolved, original trigger not yet identified

**Repro rate:** 4 of 4 occurrences, identical fault offset every time, on one physical host, over roughly a week of use. No minimal standalone repro yet — see "What's NOT confirmed" below.

### Environment

- PowerShell 7.6.5 (current latest release as of 2026-09-03 — checked, no newer point release exists that might already dodge this)
- CoreCLR `10.0.1126.37416`, commit `e2f47b0110ed922f21a1522da67279133ce28f32`
- Windows Server 2025 host
- Crash occurs inside a long-running **interactive** `pwsh.exe` session (not at process startup) — specifically during repeated Authenticode-signature-verification calls (`Get-AuthenticodeSignature`-adjacent code path) invoked from inside a PowerShell module's own per-call preamble/signature check, itself called many times across the session

### Crash data (from WinDbg `!analyze -v`, run directly against a captured full-memory dump)

```
Key : AV.Dereference Value: NullPtr
Key : AV.Type Value: Read
Key : Failure.Exception.IP.Module Value: coreclr
Key : Failure.Exception.IP.Offset Value: 0x3594df
Key : Failure.Bucket Value: INVALID_POINTER_READ_c0000005_coreclr.dll!ProcessCLRException
Key : CLR.Engine Value: CORECLR
Key : CLR.Version Value: 10.0.1126.37416

EXCEPTION_RECORD:
ExceptionAddress: 00007fffbcbd94df (coreclr!ProcessCLRException+0x13f)
ExceptionCode: c0000005 (Access violation)

IP_IN_PAGED_CODE:
coreclr!ProcessCLRException+13f [D:\a\_work\1\s\src\runtime\src\coreclr\vm\exceptionhandling.cpp @ 621]
00007fff`bcbd94df 488bd0 mov rdx,rax

FAULTING_SOURCE_LINE_NUMBER: 621
FAULTING_SOURCE_FILE: D:\a\_work\1\s\src\runtime\src\coreclr\vm\exceptionhandling.cpp
```

Fault offset `0x3594df` is identical across all 4 occurrences. Independently confirmed it falls inside `coreclr.dll`'s `.text` section (~3.5MB into the code section, verified against a byte-identical local copy of the same build) — a real executing-instruction fault, not a bad read of a data blob.

**Known imprecision, disclosed rather than smoothed over:** the disassembly at the exact fault IP is `mov rdx,rax` — register-to-register, which cannot itself raise a memory-access AV. The true faulting memory access is most likely on an adjacent instruction; without deeper tooling the exact instruction boundary isn't nailed down, so "the null-deref is at line 621's `GetCurrentExceptionTracker()` call" is the best inference from the symbol, not a confirmed instruction-level fact.

### Native call stack (`kb`, at the `.ecxr` context)

```
00 KERNELBASE!RaiseFailFastException+0x188
01 coreclr!WatsonLastChance+0x1b6 [excep.cpp @ 3564]
02 coreclr!EEPolicy::LogFatalError+0x65c [eepolicy.cpp @ 597]
03 coreclr!EEPolicy::HandleFatalError+0x129 [eepolicy.cpp @ 861]
04 coreclr!ProcessCLRException+0x161 [exceptionhandling.cpp @ 621]
05 ntdll!RtlpExecuteHandlerForException+0xf
06 ntdll!RtlDispatchException+0x437
07 ntdll!KiUserExceptionDispatch+0x2e
```

This looks like CoreCLR's own fail-fast/Watson-reporting path already responding to a fault it detected internally (frames 00-04), rather than the original triggering call — the `+0x161` return address on this stack vs. the `+0x13f` fault IP in the exception record is consistent with a second/re-entrant pass through `ProcessCLRException`, now handling its own internal AV. **The original triggering exception is not identified.**

### Precedent search — what this is NOT

- **[dotnet/runtime#121596](https://github.com/dotnet/runtime/issues/121596) / fix [PR #121602](https://github.com/dotnet/runtime/pull/121602)** — confirmed NOT a match by reading the actual diff: touches only `threads.cpp`'s `ThreadStore::HoldingThreadStore()`, a null-deref on `s_pThreadStore` triggered by early-process-startup CET-incompatibility handling. Different file, different function, different trigger window (startup vs. this mid-session crash).
- **[dotnet/runtime#45929](https://github.com/dotnet/runtime/issues/45929)** — different file (`excep.cpp`, not `exceptionhandling.cpp`), fixed in .NET 6 in 2021 — obsolete for a .NET 10 build.
- **[dotnet/runtime#111650](https://github.com/dotnet/runtime/issues/111650)** — same function, `ProcessCLRException`, but a different line (1066, not 621) and a different CoreCLR version (`8.0.824.36612`, not `10.0.1126.37416`). Still open, unresolved, `needs-author-action`. Worth linking as a related report — the same function has now surfaced null-deref-class AVs across at least 3 independent reports spanning 3 major .NET versions, though the specific lines/versions all differ enough to not call it the same bug.

### What we ruled out on our own side

A 23,000-iteration local reproduction attempt (mixed local-disk and UNC-path targets, signed and unsigned content, repeated signature-verification calls matching the crash-adjacent code path) produced **zero crashes** — real negative evidence against a torn-write/timing-race hypothesis as the trigger.

### What's confirmed vs. not

- **Confirmed:** a genuine, reproducible (4/4, identical offset), symbol-resolved fault inside `coreclr.dll`, not application code, not a timing race we could reproduce, not either of the two closest precedent bugs checked directly.
- **Not confirmed:** the original triggering exception `ProcessCLRException` was handling when it (apparently) faulted — the stack shows CoreCLR's crash-recovery response, not the moment of first fault. There is also not yet a minimal standalone repro outside this specific long-running host session.

### Can't share

The crash dump itself cannot be provided — full-memory capture of a process holding live authentication sessions, may contain live tokens in cleartext, restricted by data-handling policy on this host. Happy to answer specific questions about the dump or run additional read-only diagnostic commands against it if that helps triage.

Start with the WinDbg !analyze -v output and the captured dump, then read src/runtime/src/coreclr/vm/exceptionhandling.cpp around line 621 and the ProcessCLRException stack. Compare the behavior with dotnet/runtime#111650 while keeping the differing versions and lines in scope. Done means identifying the original triggering exception or producing a minimal standalone reproduction; neither is currently available.

Written by the indexing model from the issue text.