the Owens crash: a device reset that never waited for the device (#35)

Eight byte-identical field stacks from night 6, all one player, all in an
Owens: ParticleEngine::Destroy +0x11, access=0 target=0x0, from the plain
per-frame render path. Nothing in the stack touches weapons or the Owens.
Conn Man's Surface Pro 9 (Iris Xe, 128 MB shared) is simply the only GPU in
the fleet that ever actually LOSES the D3D9 device -- his two-trigger
missile+laser bursts are what provoke the timeout, not what crashes.

What crashed is our device-loss handling, which was wrong three ways at once,
in two inline copies (the scene Present and the wait-screen Present):

  1. On D3DERR_DEVICELOST it called Reset() IMMEDIATELY. Reset on a
     still-lost device ALWAYS fails, and V() only logs. There was no
     TestCooperativeLevel gate at all.
  2. It then ran ParticleEngine::Initialize against the lost device. The
     creates fail there and NULL their out-params -- proven, not assumed:
     the bench repro faults at target=0x0, not at a dangling address.
  3. The next lost frame called ParticleEngine::Destroy again, which
     Release()d those NULLs blind. Read of vtable at 0x0. Dead.

So: lost frame 1 tears down and leaves NULLs, lost frame 2 crashes. Two
frames, every time, deterministic -- which is exactly why all 8 field stacks
are byte-identical.

Reproduced before fixing. BT_DEVICELOST_TEST=<frame>,crashrepro runs the
field sequence on the bench; on the unfixed build it died at Destroy +0x11,
access=0 target=0x0, and symbolized to the same four frames as the field
logs. Same shape, same offsets-modulo-hook. That run also proved the
out-param-nulling assumption the whole diagnosis rested on.

The fix -- one shared DPLRenderer::BTResetLostDevice() replacing both inline
copies:

  - Destroy() is idempotent and null-safe, and nulls after release.
  - Reset() is gated on TestCooperativeLevel() != D3DERR_DEVICELOST; while
    the driver still says lost, skip the frame and retry.
  - The Reset HRESULT is checked; on failure, log and retry next frame
    instead of driving on.
  - On success, re-create via the new CreateDeviceObjects(), NOT
    Initialize(): Initialize memsets the installed-effects table, so every
    reset that DID succeed silently killed all particle effects for the rest
    of the mission. The quieter sibling bug, fixed by the same split.
  - Initialize checks its HRESULTs and defends MAXPARTICLES<=0; the draw
    paths guard the NULL buffer, and ExecuteParticles keeps draining
    particles while the engine is dormant so they cannot pile up.

Verified: the crashrepro shape now logs SURVIVED and play continues; three
forced full loss/reset cycles each log "[render] device reset OK"; a plain
run is assert-free.

Found while verifying, worth its own line: VIDEO\particles.png has NEVER
existed -- not in the tree, not in BTL4.RES, not anywhere in git history.
The texture load has failed on every machine since the engine was written,
and every billboard particle ever rendered was untextured quads via
SetTexture(0, NULL). RenderParticles deliberately does NOT gate on the
texture -- that would disable all particles everywhere; untextured IS the
shipped look. Filed separately; a real particle sheet is a content task.

The field verification that counts is Conn Man flying his exact crash
loadout on this build: instead of a dead process he should see at worst a
brief hitch and "[render] device reset OK" in his log. #35 stays open until
that happens.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

context/decomp-reference.md

@@ -473,6 +473,7 @@ default-ON (`'0'` disables).
 | `BT_SELF_DAMAGE=<dps>` | dispatch an unaimed `TakeDamage` at your OWN mech once a second, through the real `Entity::Dispatch` path, so the whole RESPAWN family is bench-testable solo (nothing else can kill the local pilot: `BT_MP_FORCE_DMG` only targets replicants). **Latches off at first death** so everything after the respawn is the respawn's doing, not the harness still shooting you |
 | `BT_POWER_DETACH_TEST=<name\|1>` | drop a subsystem's voltage link + force Auto, so the auto-hunt must recover it. `1` = first powered subsystem to tick; a NAME (`PPC_1`, `Myomers`) targets one, which is what proves FAILOVER to a different generator rather than a same-generator re-attach |
 | `BT_AUDIO_SOURCES=<n>` | request `n` OpenAL mono sources instead of the driver default (~256). **Opt-in on purpose** — the cap doubles as a governor, and with EFX reverb live a higher ceiling means more simultaneous voices mixing during heavy combat. Measure frame time. See [[wintesla-port]] |
+| `BT_DEVICELOST_TEST=<frame>[,crashrepro]` | #35 bench hook. `<frame>` forces the D3D9 DEVICELOST branch at that render frame (+600/+1200 = 3 cycles), driving the REAL `BTResetLostDevice` recovery. `,crashrepro` runs the field null-teardown shape (double `ParticleEngine::Destroy`) — pre-fix this reproduced the field crash byte-for-byte (`Destroy +0x11`, `target=0x0`); post-fix it must log `SURVIVED`. See [[wintesla-port]] §Device-loss |
 
 Full render/locomotion gates (BT_RAMP, BT_MATPRI, BT_CULL, BT_SHADOW_*, BT_LODSEL, BT_ADDLOD,
 BT_PUNCH, …) are catalogued in [[rendering]]. Warp visuals: [[translocation-warp]].

context/multiplayer.md

@@ -676,7 +676,9 @@ Only the relay host needs port forwarding.  Verified: scripted protocol suite in
 2-node mission launched + stopped purely over the socket.
 
 ## The interest-teardown audio crash (2026-07-24) [T2 stack-captured + fixed]
-THE layout-shifting release-only crash (weeks of field flakes, #35's prime suspect) finally
+THE layout-shifting release-only crash (weeks of field flakes; was #35's prime suspect until
+2026-07-29 CLEARED it — #35 turned out to be the ParticleEngine device-reset null-deref, root-caused
+from 8 symbolized field stacks and fixed; see [[wintesla-port]] §Device-loss) finally
 hit a crash-filter build: `InterestManager::OrphanInterestOrigin → RemoveUninterestingEntity
 → DestroyEntityAudioObjects → {Static,Dynamic}3DPatchSource::IsAudioSourceClipped` — AV
 reading NULL+0x38: the authentic burning-mech death-silence check dereferences

context/wintesla-port.md

@@ -16,6 +16,30 @@ on top of it. Full detail: `docs/PROGRESS_LOG.md §5b, §8`.
 ## What WinTesla already did (do NOT rebuild)
 - **Renderer bypass: DONE** — `MUNGA_L4/L4D3D.cpp` + `DXUtils` replace libDPL / the IG board with
   Direct3D9. No `libdpl.lib` in the tree. (The early from-scratch D3D9 viewer was retired and removed.) [T1]
+- **Device-loss: the #35 "Owens crash" — ROOT-CAUSED + FIXED 2026-07-29** [T2, bench-reproduced].
+  8 byte-identical field stacks (one player, Surface Pro 9 / **Iris Xe 128 MB** — the only GPU in
+  the fleet that ever actually loses the device): `ParticleEngine::Destroy +0x11`, `access=0
+  target=0x0`, from the per-frame render path. **Not a weapons bug** — the Owens two-trigger
+  missile+laser combo is merely what provokes the GPU timeout on that iGPU. The broken protocol
+  (both Present sites, inline copies): on `D3DERR_DEVICELOST` they called `Reset()` IMMEDIATELY —
+  which **always fails while still lost** (`V()` only logged) — then `ParticleEngine::Initialize()`
+  ran against the lost device, its creates failed and **NULLed the out-params** (verified: the bench
+  repro faulted at `target=0x0`, not a dangling address), and the NEXT lost frame's blind
+  `mVertBuffer->Release()` read a vtable at 0x0. FIX (`L4VIDEO.cpp` + `L4PARTICLES.cpp`): one shared
+  `DPLRenderer::BTResetLostDevice()` — release POOL_DEFAULT resources every lost frame (idempotent,
+  null-safe `Destroy`), **gate `Reset()` on `TestCooperativeLevel() != D3DERR_DEVICELOST`**, check
+  the Reset HRESULT, and on success re-create via **`CreateDeviceObjects()` — NOT `Initialize()`**,
+  whose `memset(mInstalledEffects)` silently killed every particle effect for the rest of the
+  mission on each reset that DID succeed (the quieter sibling bug). Draw paths guard the NULL buffer
+  (`ExecuteParticles` keeps draining particles while dormant). Bench: `BT_DEVICELOST_TEST` repro'd
+  the field crash byte-for-byte pre-fix, and post-fix the same shape logs `SURVIVED` + 3 forced
+  loss/reset cycles recover (`[render] device reset OK`).
+  ⚠ **Discovery from the verify: `VIDEO\particles.png` has NEVER existed** — absent from the tree,
+  the RES, and all of git history — so `mParticleTexture` has been NULL on every machine since the
+  engine was written and **all billboard particles draw as untextured quads** (`SetTexture(0,NULL)`
+  = the shipped look). Deliberately NOT gated on in `RenderParticles` — that would disable all
+  particles everywhere. Filed on the tracker; a real texture (or the original particle sheet) is a
+  content task. Possibly related to the field "missile artifact looks wrong" observation.
 - **Audio SOURCE BUDGET — the dropout complaint was fixed 2026-07-23; the leftover is NOT the same
   bug** [T2, 2026-07-28]. **The reported bug is closed**: `a999e5c` (per-source delete instead of the
   spec-atomic bulk `alDeleteSources`) stopped the pool leaking, and there have been **no field