1. DigitalPour.ServerBasedAgent — Crash Dump Analysis (WinDbg)

*Date analyzed:* 2026-06-16
*Dumps examined:* 2 of 5

• `DigitalPour.ServerBasedAgent.exe.3468.dmp` (6/16/2026, 3.4 GB)
• `DigitalPour.ServerBasedAgent.exe.7292.dmp` (6/14/2026, 1.26 GB)
  *Runtime:* .NET 10, CoreCLR `10.0.926.27113` @Commit `901ca941248413c79832d2fdbd709da0c4386353` (retail)

—

1. 1. Bottom line

Both crashes occur *inside the JIT compiler while compiling dynamically-generated code that originates from the MongoDB driver's LINQ3 query provider.* They are *not* in the GC, and they do *not* involve `JToken`/`JObject`/`JArray`.

The managed GC heap verified *completely clean. The original root-cause theory (JToken graphs reachable across `await` points → GC follows stale pointers during Gen2 → corruption) is **not supported by the dumps.*

—

1. 1. Evidence

1. 1. 1. Dump 3468 (6/16)

Exception record (`.exr -1`):

```
ExceptionCode:  c0000005 (Access violation)
Parameter[0]:   0  -> READ
Attempt to read from address 00000110458eccb0
ExceptionAddress: coreclr!memcpy+0x181
```

Faulting stack (top frames):

```
0b coreclr!memcpy+0x181
0c coreclr!LCGMethodResolver::GetCodeInfo+0xed
0d coreclr!CEEInfo::getMethodInfoWorker+0x393
0e coreclr!CEEJitInfo::{ctor}
0f coreclr!UnsafeJitFunction+0x223
10 coreclr!MethodDesc::...JitCompileCode...
```

The JIT was copying a *dynamic method's IL* (`LCGMethodResolver` = Lightweight Code Generation, i.e. `DynamicMethod` / `Reflection.Emit`). `!address` on the faulting pointer:

```
State:           MEM_RESERVE        <- reserved, NOT committed
Content source:  0 (invalid)
```

So the JIT was handed a *dangling IL pointer into uncommitted/garbage address space.* Lower stack frames are a long chain of MongoDB driver async continuations.

1. 1. 1. Dump 7292 (6/14)

Exception record (`.exr -1`):

```
ExceptionCode:  c0000005 (Access violation)
Parameter[0]:   0  -> READ
Attempt to read from address 0000000000000004
ExceptionAddress: coreclr!ArrayBase::GetDataPtrOffset+0x3
```

Faulting stack (relevant frames):

```
12 coreclr!MethodDesc::JitCompileCodeLocked
14 coreclr!MethodDesc::JitCompileCode
15 coreclr!MethodDesc::PrepareILBasedCode
17 coreclr!MethodDesc::PrepareInitialCode
18 coreclr!MethodDesc::DoPrestub
19 coreclr!ReflectionInvocation_CompileMethod
1a System.Linq.Expressions.Compiler.LambdaCompiler
1b MongoDB_Driver!MongoDB.Driver.Linq.Linq3Implementation...
...
27/28/2e DigitalPour.ServerBasedAgent.ViewModel (async)   <- ProcessLocation path
```

This is JIT-compiling an *expression-tree lambda built by MongoDB's LINQ3 provider at query time* (`LambdaExpression.Compile` → dynamic method → JIT). The JIT read a near-null array reference (`0x4`).

1. 1. 1. Heap integrity (Dump 3468)

```
!verifyheap
1,544,531 objects verified, 0 errors.
No heap corruption detected.
```

1. 1. 1. About the FailFast

The visible top frame is `KERNELBASE!RaiseFailFastException`, reached via
`RtlDispatchException → CLRVectoredExceptionHandler → EEPolicy::HandleFatalError → LogFatalError → WatsonLastChance`.
That is just the CLR converting the hardware AV into a fatal process kill. It is the messenger, not the cause.

—

1. 1. Interpretation

Two *different* fault sites (a dangling IL pointer into uncommitted memory; a near-null array reference) both feed the *JIT* bad inputs, while the *GC heap is clean. Both originate from **dynamic code generation in MongoDB's LINQ3 provider*, hit on parallel worker threads.

That pattern indicates either:

• a *concurrency race* in the dynamic-code-gen / JIT path (the app fans all locations out in parallel via `Task.Run`, and LINQ3 compiles expression trees per query), or
• a *.NET 10 JIT regression* (brand-new runtime; fault is deep inside the JIT).

It is *not* GC heap corruption and *not* the JToken-across-await mechanism. The `JToken = null` fixes only shift GC timing, which is why uptime wobbled between runs (~2 days vs <24 h) without ever fixing the crash.

—

1. 1. Recommended next steps (in priority order)

1. *Run the agent on .NET 8 LTS.* Cheapest, most decisive test. If the crash vanishes, it's a .NET 10 regression — done.
2. *Throttle the parallel `Task.Run` fan-out* across locations with a `SemaphoreSlim` (limit max degree of parallelism). If it's a race in concurrent expression compilation, serializing it should eliminate the crash and confirm the cause.
3. *Update `MongoDB.Driver` to latest, and consider forcing the **LINQ2 provider* (`LinqProvider.V2` on the `MongoClientSettings`) to sidestep LINQ3's per-query expression compilation. Reusing/caching queries reduces JIT churn.
4. *Test `DOTNET_TieredCompilation=0`* (optionally `DOTNET_TC_QuickJitForLoops=0`, `DOTNET_ReadyToRun=0`) to probe a tiered-JIT race.
5. If it survives 1–4, you have a clean repro. *File with dotnet/runtime and mongodb/mongo-csharp-driver*, citing CoreCLR build `10.0.926.27113` and the two stacks above.

—