Controlled follow-up: failed GPU reset, 2026-09-16 22:57 CEST

Result: the combined direct-rendering and disabled-SRP-batcher configuration did not fix the failure. Windows recorded a fresh NVIDIA TDR during continuous driving, well before a finish or lap boundary. This is evidence against the finish transition being a necessary trigger; it does not establish that all historical incidents share one cause.

Configuration and actual outcome

The invocation requested 180 seconds, alps-02, Low, Rain seed 707000, 1920×1080, full scenery/effects, Direct3D11, -force-gfx-direct, and -rampageNoSrpBatcher. The player log confirms Unity 6000.3.24f1, RTX 4060 Laptop, driver 32.0.16.1692, kGfxThreadingModeDirect, and enabled=False pipelineReady=True for the SRP batcher. The flight recorder independently confirms graphicsMultiThreaded=false and srpBatcher=false. Renderer configuration differed from production; the legacy fullProductionConfiguration field describes scenery/effects, not default submission settings.

The report is incomplete and failed: 0/1 visits, no valid duration or crossing coverage, last checkpoint at 39.3868 test seconds / 26.1260 race seconds. The wrapper subsequently recorded a driver-reset failure and confirms production profiles unchanged and QA files restored. These final cleanup results supersede the incomplete report's initial false placeholders. ExitCode is null; no successful process exit is claimed.

The user clarified that the manual failure occurred immediately before the lap 1→2 crossing and hung the whole system. This controlled run selected point-to-point alps-02 (closedCourse=false), so it is not an exact reproduction of that lap transition. It nevertheless reproduced the GPU failure before any boundary was reached.

Correlated timeline

The flight recorder has 36 samples, all finite, zero recorded managed errors, and no clean-exit record. In the last sample the player was grounded/on-road, not crashed/finished, gates 28/90, distance 1,254.63 m / 4,024.81 m, speed 166.66 km/h, position (-1569.78, 376.23, 2124.55). No completed lap or lap transition was recorded. The player log ends after the continuous-race phase begins, without a device-loss footer. A clean-looking or truncated player log therefore cannot establish success.

GPU and system memory

The 53 adapter-wide GPU samples show maxima of 2,118/8,188 MiB, 65 °C, 57% utilization, 41.07 W, and 2,670 MHz. The last pre-event sample, at 22:57:49.271, was 1,973 MiB, 64 °C, 48%, 40.22 W. The subsequent 22:57:50.283 sample repeats these counters and should not be interpreted as completed rendering after the reset.

System telemetry shows at least 48.65 GB physically available, maximum commit 23.71/72.63 GB, and maximum player working set 0.898 GB. The previous 20:08 Vulkan failure ended around 2,119 MiB, 69 °C, 46.95 W, with about 43.9 GB RAM available. Neither run supplies evidence for ordinary VRAM/RAM exhaustion or temperature saturation. Low aggregate use does not exclude invalid resource access, an unsampled spike, or a workload-specific GPU/driver defect.

Five remaining hypotheses, ordered for investigation

1. Invalid or unstable Unity/HDRP GPU commands or resource lifetime in this workload. Cross-API full-scene failures, earlier D3D12 CBV validation errors, and minimal-scene passes keep this plausible. The new run excludes direct-thread submission plus SRP-batcher removal as a sufficient cure; it does not locate an invalid command.
2. NVIDIA driver/WDDM or hybrid graphics interaction triggered by this workload. The direct evidence is a hardware-driver timeout and difficult recovery. Other games being stable is compatible with a workload-specific driver defect. The event name alone does not assign fault to NVIDIA or prove defective hardware.
3. A specific scenery/instancing/material path or its workload combination. Prior geometry-baseline and no-billboard isolation passes offer a direction, but the stock HDRP/Unlit tree replacement also reset, and some passes used reduced effects. No individual shader or instancing draw is convicted; the current crash location is only the last sampled position.
4. Capture/overlay injection or undocumented driver overrides. NVIDIA injection modules were present in earlier processes, but also in passing controls. Public profile inspection was not a full audit of undocumented options. This remains lower-confidence and requires attribution, not an assumption that a loaded DLL caused the fault.
5. GPU/firmware/platform instability specific to this rendering pattern. The system-wide freeze makes the kernel/platform relevant, but moderate sampled temperature, memory and power plus stable other games do not support a broad hardware-failure claim. Existing samples cannot fully exclude this category.

Sampled finite transforms weaken a simple NaN/Infinity physics explanation but do not validate every GPU buffer or every frame. The early TDR weakens a lap-boundary-only explanation. None of the five hypotheses is proven.

Next step using the existing failure

Obtain readable copies of the new WATCHDOG-20260916-2257.dmp or its WER queue copy Kernel_117_73524eb0d5c1eaa963c9495eea9433f524f06b_00000000_927e4fee-ce94-4910-8ad5-5dc3404ee070, plus the earlier 091626-13375-01.dmp. The latest WER evidence identifies these records; prior direct file checks showed missing live paths and access denied for queue/minidump access. An administrator-authorized copy is required where Windows denies ordinary access. Analyze the copies with matching Microsoft/NVIDIA symbols and record stack, timeout context and module versions. The older 0x133 dump and newest 0x117 record must remain distinct. No additional GPU run is needed to acquire or analyze these existing artifacts.

This audit only read existing test outputs and wrote this summary. It launched no player or GPU workload and changed no source or system setting.