dotnet build crashes with 0xC0000005 in coreclr.dll thread pool on Windows 11 25H2 / Intel Arrow Lake; .NET Framework MSBuild is stable

### Description

### Description

`dotnet build` (MSBuild running on .NET 10) crashes intermittently with an access violation (`0xC0000005`) in `coreclr.dll` on a specific machine configuration. The crash is **specific to the .NET (Core) runtime's thread pool**: .NET Framework MSBuild builds the same project with 0 crashes, and .NET 8-based processes never crash.

Key facts:

- Crash signature is **deterministic**: faulting module `coreclr.dll` (Microsoft.NETCore.App 10.0.10), exception `0xC0000005`, **same fault offset `0x000000000035967f`** on every occurrence (Windows Event Log, Application Error 1000).
- Crash stacks (Event Log 1026 / stderr) point to the thread pool / Task infrastructure:
- `System.Threading.PortableThreadPool+WorkerThread.WorkerThreadStart` → `Thread.StartCallback` → `ThreadPoolWorkQueue.Dispatch`
- `Microsoft.DotNet.Cli.Program.ProcessArgs` / `Program.Main` (the dotnet CLI host itself)
- `Microsoft.Build.BackEnd.RequestBuilder.RequestThreadProc`
- occasionally `Task+DelayPromise..ctor`
- Also observed intermittently: `Starting the CLR failed with HRESULT 80004003 (E_POINTER)` when launching `dotnet build`.
- JetBrains Rider's backend (bundled .NET 10.0.5 runtime) crashes with the same `0xC0000005` in `coreclr.dll` (offset `0x3585bf`), and a PowerShell 7 (on .NET 10) process crashed once with `AccessViolationException` in `System.Linq` during module autoload.
- **CET / shadow stacks are NOT involved on this machine**: the OS-level "Hardware-enforced Stack Protection" is Off, and a probe in a .NET 10 process reports `IsProcessorFeaturePresent(PF_SHADOW_STACK_ENABLED=84) == False`. The crash still occurs. (Related issues #10177 / #121596 / #115768 implicated CET; on this machine CET is disabled and the crash persists.)

### Reproduction Steps

Machine: Windows 11 25H2 (OS build 26200), **Intel Core Ultra 7 265K (Arrow Lake, 20C/28T, P+E cores)**, Huorong security software installed, HVCI (Memory Integrity) enabled.

1. Install .NET SDK 10.0.400 (runtime 10.0.11).
2. Create any project (e.g. `dotnet new console`) — the SDK tooling itself runs on .NET 10, so the target framework doesn't matter (net8.0 reproduces too).
3. Run `dotnet build` in a loop:
```powershell
for ($i=1; $i -le 8; $i++) { dotnet build; echo "exit: $LASTEXITCODE" }
```
Result on this machine: ~50% of invocations exit with `-1073741819 (0xC0000005)`.

Secondary repro (shows the crash is in the tooling, not in user code):

1. Create a net10.0 console app with heavy thread-pool churn (`Task.Delay(1).Wait()` × 300, `Parallel.For`, `Thread.Sleep`).
2. `dotnet run` it repeatedly: crashes intermittently (~50% before SDK 10.0.400, ~1/6 after).
3. Run the built `exe` directly: **0 crashes in 12 runs**. The crash only affects the `dotnet` CLI host / MSBuild / compiler-server processes.

### Expected behavior

`dotnet build` / `dotnet run` complete reliably on every invocation.

### Actual behavior

Intermittent `0xC0000005` access violation in `coreclr.dll` (thread pool / Task code), roughly 50% per `dotnet build` invocation on this machine. Recoverable by retrying (`dotnet build-server shutdown` improves reliability). Crash rate drops to ~17% with `dotnet build -m:1` (fewer worker threads), which points at the thread-pool code path as the fault location.

### Regression?

| Build method | Runtime | Crashes |
|---|---|---|
| `dotnet build` (SDK MSBuild) | .NET 10 (10.0.11) | 4/8 (50%) |
| `dotnet build -m:1` | .NET 10 (10.0.11) | 1/6 (17%) |
| `dotnet build -p:UseSharedCompilation=false` | .NET 10 (10.0.11) | still crashes (MSBuild's own threads) |
| Rider-bundled **MSBuild.exe 18.7.8 on .NET Framework 4.8** (build only, no `/restore`) | .NET Framework | **0/6** |
| Rider-bundled MSBuild.exe with `/restore` | .NET Framework | 5/6 (1 crash, possibly in restore step) |
| User-built net8.0 / net10.0 exe run directly | .NET 8 / 10 | 0/12 |
| Godot editor in-process MSBuild (hosts .NET 8) | .NET 8 | never crashes |

### Known Workarounds

_No response_

### Configuration

- OS: Windows 10 Pro (reporting), DisplayVersion 25H2, build 26200
- CPU: Intel(R) Core(TM) Ultra 7 265K (family 6, model 0xC6), 20 cores / 28 threads
- SDKs installed: 8.0.129, 10.0.302, 10.0.400
- Runtimes installed: 6.0.36, 8.0.29, 9.0.18, 10.0.10, 10.0.11
- Security software: Huorong (HipsDaemon) + Windows Defender; adding `C:\Program Files\dotnet` to Huorong's whitelist did NOT change the crash rate
- HVCI (Memory Integrity): enabled
- No WHEA hardware error events logged; 5× Event 41 (unexpected shutdown) in the last 10 days (possibly unrelated)
- Windows Event Log: `Application Error 1000` with `Faulting module: coreclr.dll` version 10.0.10, offset `0x35967f`, for `dotnet.exe`; also for `Rider.Backend.exe` (bundled coreclr 10.0.5, offset `0x3585bf`)

### Other information

- The deterministic fault offset in `coreclr.dll` suggests a specific code path in the thread pool rather than random memory corruption.
- The crash predominantly affects processes running on the .NET 9/10 runtime (dotnet CLI, MSBuild nodes, csc/VBCSCompiler, Rider backend, PowerShell 7). .NET 8 and .NET Framework MSBuild workloads are stable in repeated tests. A rare, possibly related, instability also hit a .NET Framework process (Windows PowerShell 5.1) once under heavy process-spawning load, and Task Manager crashed once with heap corruption — so there may be a small system-level component on top of the .NET 10 issue.
- `-m:1` reduces the crash rate, consistent with a thread-creation / worker-thread path.
- **Attaching a debugger suppresses the crash**: 10/10 runs under procdump (debugger-attached, `-e -ma -x`) completed without crashing, while bare runs on the same machine crashed 37% (3/8). This strongly suggests a timing-sensitive race in the thread-pool code path.
- **Crashed builds can leave corrupted artifacts**: after a crash during build, `bin/Debug//.runtimeconfig.json` was left truncated, causing subsequent runs to fail with `Failed to parse runtimeconfig.json` until a clean rebuild. (Side effect of the crash mid-write.)
- The machine-specific nature (this machine crashes at ~50%; user apps never crash) may indicate an interaction with the machine's CPU topology (Arrow Lake P+E cores) and/or security-software thread hooks — but the deterministic offset suggests a runtime bug that these conditions merely trigger.

Related issues: #10177, #121596, #115768, #110920 (those implicate CET shadow stacks; on this machine CET is confirmed disabled, yet the crash persists — this may be a separate manifestation or the true root cause differs).
The crash dump (procdump/WER) may be helpful.
https://drive.google.com/file/d/1Q_LgtoQUvt_61xyJl2G4brgwQ01Lhl-m/view?usp=sharing