Reproducible render freeze ~236s after load, at RansackedStation2-2 encounter respawn (2.4.0.95)

SUMMARY

Loading the attached save and doing nothing produces a permanent render-thread freeze at a fixed point in world simulation. The GPU faults 235.97 s (+/- 0.25 s) after the first "Spawn SpaceEncounter" line in the game log - five sessions out of five. Every time, it happens 3.8 s after the same encounter, SpaceEncounter_RansackedStation2-2_Composite (3468 PCU), despawns from sector [-1989,-1721,-1902] and respawns at [-1991,-1723,-1903].

The render thread never recovers. The watchdog writes its dump, logs "Still frozen" every 5 s indefinitely, and the process has to be killed.

STEPS TO REPRODUCE

1. Load the attached save "Jim1" (single-player, world seed -1740858954).

2. Do nothing. Idle at the player's base.

3. ~236 s after the first "Spawn SpaceEncounter" entry appears in the log (roughly four minutes of world time), the render thread freezes permanently.

Reproduced 5/5. Player activity is irrelevant - four sessions were normal play, one was idling in the inventory screen at base. The encounter spawn/despawn cycle runs on the world simulation's own timer and replays identically from this save, which is why the timing is repeatable to a fraction of a second.

TIMING (offsets from the first encounter spawn; identical in all 5 sessions)

+0.0 Spawn [-320, -1068, -2633] SpaceEncounter_AsteroidTinyHome2-2

+5.2 Despawn [-318, -1064, -2628] SpaceArmedGladiusShipwreckEncounter

+17.8 Spawn [-1987, -1715, -1900] SpaceEncounter_DebrisFieldNova352-2

+44.1 Spawn [-1990, -1715, -1900] SpaceEncounter_Nova35Shipwreck2-2

+74.9 Despawn [-320, -1067, -2630] SpaceEncounter_AsteroidTinyHome2-2

+83.5 Despawn [-1990, -1715, -1900] SpaceEncounter_Nova35Shipwreck2-2

+83.5 Despawn [-1987, -1715, -1900] SpaceEncounter_DebrisFieldNova352-2

+127.9 Spawn [-1989, -1721, -1902] SpaceEncounter_RansackedStation2-2 (3468 PCU)

+164.4 Spawn [-320, -1071, -2637] SpaceEncounter_ShatteredAsteroid2-2

+164.5 Spawn [-1990, -1721, -1903] LOE_AsteroidBase1Encounter

+174.1 Spawn [-322, -1067, -2638] SpaceCenterlineH2ShipwreckEncounter

+179.4 Despawn [-320, -1068, -2633] SpaceEncounter_AsteroidTinyHome2-2

+213.4 Spawn [-1990, -1719, -1904] SpaceArmedGladiusShipwreckEncounter

+222.7 Spawn [-1994, -1720, -1901] SpaceEncounter_AbandonedCargo2-2

+222.7 Spawn [-1994, -1718, -1900] SpaceEncounter_AsteroidTinyHome2-2

+229.5 Despawn [-1989, -1721, -1902] SpaceEncounter_RansackedStation2-2 <-- despawn

+232.2 Spawn [-1991, -1723, -1903] SpaceEncounter_RansackedStation2-2 <-- respawn

+236.0 >>> GPU context timeout, render thread freezes <<<

Session first spawn GPU fault offset

260913_102307 10:24:38.952 10:28:35 236.05 s

260913_102932 10:31:03.030 10:34:59 235.97 s

260913_125153 12:54:51.923 12:58:48 236.08 s

260913_130902 13:11:04.174 13:15:00 235.83 s

260913_135846 14:00:41.078 14:04:37 235.92 s

mean 235.97 s, spread 0.25 s

Note: one useful negative. In a separate session loaded from a later autosave, the same RansackedStation2-2 encounter DESPAWNED from [-1991,-1723,-1903] with

no freeze. The despawn alone is not sufficient - it is the despawn/respawn pair, or the respawn specifically.

FAILURE CHAIN

14:04:37 kernel: NVRM: Xid (PCI:0000:3e:00): 109, pid=134715,

name=Main Thread, channel 0x0000000e,

errorString CTX SWITCH TIMEOUT, Info 0x1c013

14:04:43.2 [Watchdog]: The application froze with freeze type

RenderThreadFreeze (freeze #1). Capturing dump.

then [Watchdog]: Still frozen (RenderThreadFreeze) for N s ...

repeating every 5 s until the process is killed.

Sessions allowed to run to completion continue:

RenderException: FlushAllQueuesAndWaitCpu failed to synchronize CPU with the GPU command queue 'Direct'

CLR: "Attempt to execute managed code after the .NET runtime thread state has been destroyed" (ceemain.cpp:1827)

exit 0xC0000602 (STATUS_FAIL_FAST_EXCEPTION)

So: a GPU context wedges, the D3D12 fence on the Direct queue never signals, FlushAllQueuesAndWaitCpu blocks forever, the watchdog fires. The Xid names the faulting context "Main Thread". The channel id varies run to run (0x0c / 0x0d / 0x0e); the Xid number and the timing do not.

GPU TELEMETRY THROUGH THE FAULT (nvidia-smi at 5 Hz, relative to the Xid)

t-Xid power clk_sm temp util mem(MiB)

-3.56s 117.3W 1965 57 47 7035 normal play

-3.01s 102.2W 1965 55 100 7035 <-- util pins to 100%, power FALLS

-2.20s 77.2W 1965 54 100 7035

+0.01s 76.6W 1965 54 100 7035 <-- Xid 109 logged

+0.81s 75.5W 1965 53 0 7035 <-- driver drops the channel

+2.81s 55.8W 510 51 0 7035 clocks idle down

+5.83s 26.5W 210 49 0 7035 GPU fully idle

For three seconds before the fault the GPU reports 100% utilization while power DROPS from 117 W to 77 W: the engine is occupied but retiring nothing. Work was

submitted and never completed, and the context-switch timeout then fired. Clocks never waver. Afterwards the GPU goes fully idle while the render thread stays

blocked on the fence, and memory.used never drops off 7035 MiB - the context is never torn down.

ALREADY EXCLUDED LOCALLY

VRAM exhaustion - flat at 86% of budget (6.15 / 7.13 GB), ~1 GB spare,

no spike or creep before the freeze

GPU load - 6.5 ms frame time, 7.2 ms worst case, right up to it

GPU power delivery - max 117.6 W against a 240 W limit; 0 of 2783 samples

above 150 W

Thermal throttling - max 58 C, clocks steady at 1965 MHz until after the fault

System RAM / OOM - 64 GB, ~5.5 GB in use, no OOM kills

Storage errors - zero NVMe / filesystem / I/O errors in 14 days

Display hotplug - no modeset, EDID or link-training events at crash time

Player action - reproduces while stationary and idle

ENVIRONMENT

Game version 2.4.0.95 (.NET 9.0.19)

OS Linux Mint 22.3 (Ubuntu 24.04), kernel 6.8.0-139

Runtime Proton 10.0-4 + SteamLinuxRuntime_sniper (D3D12 via vkd3d-proton)

game self-reports as "Microsoft Windows 10.0.19045"

GPU NVIDIA GeForce RTX 3070 8 GB, driver 610.43.02 (open module)

NvApi reports 61043 (r57594_proton-10.0-4b+)

CPU / RAM Ryzen 9 5900X, 64 GB

Display 3840x1080 (2x 1080p), Medium preset, FSR Quality, RT off

Launch options none

Mods none

I am on Linux via Proton, and I realise that may be out of scope for support. The reproduction is save-attached and deterministic, so it should be testable on Windows in a few minutes:

1. Load the attached save on Windows and idle for five minutes. If it freezes there too, this is a renderer/encounter issue and the platform is irrelevant.

2. If it does not reproduce on Windows, the D3D12 command stream generated around the RansackedStation2-2 respawn is still worth a look - something in it hangs a GPU context rather than merely being slow.

Happy to run any instrumented build, capture, or additional test you'd like - the repro takes four minutes and I have the save preserved.

ATTACHMENT

se2-ransackedstation-freeze.zip - contains the reproducing save, two complete crashing session logs, the watchdog minidump, the 5 Hz GPU telemetry CSV, and the kernel Xid lines. See README.txt inside.