#1234 Windows/RTX 4090 (0.1.39): stall report stage "decode -1" for 61 s; 0 layers served - thread stacks attached

Beschreibung

**Engine:** 0.1.39 (Windows 11, RTX 4090, IQ3_XXS native pack, 128K context, `--spec 4`, `--kv k8v4 --kv-resident 32768`, 23 expert-pool workers)

**What happened**

During a long session (prompt ~38.8K tokens, healthy previous request at 50 tok/s with 86–89% expert cache hit rate) generation stopped mid-request:

```
strata serve: no progress for 60 s during a request (decode -1) - stopping the engine so the server starts it again (issue #29)
strata serve: stall report (engine 0.1.39): stage "decode -1" for 61 s; 0 layers served since the last finished step (0 = stopped, more = slow)
```

**Stall report (as captured, twice 2 s apart, identical both times):**

```
expert pool: epoch 1046406, batch epoch 1046406: 72 of 72 jobs claimed, 72 done; 23 of 23 workers parked, 23 sleeping; mode 0
expert pool threads: w0..w22 all sleeping; host idle for 61115 ms
verify window (last window, not the current stage): 4 tokens at position 38817, host at layer step 48; the GPU rang 48; flags: served 48, plan (A) 48, copies (B) 48
memory: 44362 MiB resident, 67599 MiB committed, 5394 MiB RAM available; 16061911 page faults so far
```

After the report, the engine released the verify window's GPU waits (`released the verify window's GPU waits (#267): the GPU did not finish within 5 s`) and the server restarted it; the next request ran normally.

**Thread stacks:** attached as the docs request (`docs/DETAILS.md`: "on Windows, a `strata-stall-<pid>.dmp` file with every thread's stack: attach both"). Personal identifiers (account name, user SID fragments, hostname) were scrubbed from the dump with equal-length byte replacements; structure intact.
Download (base64): https://gist.githubusercontent.com/skankmoses/c569bf1c569429ebaf8e782f42789292/raw — decode with `base64 -d strata-stall-40888.dmp.b64.txt > strata-stall-40888.dmp` (decodes to the original 351,358-byte file)

**Context / possible confounder**

The host was under commit-memory pressure at the time (system-managed page file, ~23 GB allocated, commit headroom <1 GB). Since then I fixed the page file to a fixed 48 GB and granted "Lock pages in memory"; on 0.1.40 the stall has not recurred, so this may have been a memory-starvation symptom rather than a standalone engine bug. Posting the dump anyway since the docs ask for these, in case the thread stacks are useful for the triage table (#29/#31/#267 family).