Xid / GPU lost crash on RTX PRO 4000 Blackwell during LLM inference (Ollama, Windows 11 + WSL2, Driver 595.79)

Infrastructure & Networking Software And Drivers
1

Summary

NVIDIA RTX PRO 4000 Blackwell (PNY VCNRTX4000B-PB) enters an unrecoverable fault state during LLM inference workloads under Ollama running in WSL2. After the crash, nvidia-smi reports “GPU is lost. Reboot the system to recover this GPU” for the PRO 4000, while the RTX 4060 Ti in the same system remains fully functional. A soft reboot does not recover the GPU — a full PSU power cycle is required.

This appears to match the Xid 62 / Xid 154 GSP firmware crash pattern reported in these threads:

System Information

  • GPU 0 (display): NVIDIA GeForce RTX 4060 Ti (unaffected)

  • GPU 1 (compute): NVIDIA RTX PRO 4000 Blackwell — PNY VCNRTX4000B-PB

  • Driver: 595.79 (NVIDIA Studio Driver, Windows)

  • CUDA: 13.2

  • CPU: AMD Ryzen 9 7900X

  • RAM: 128 GB

  • Motherboard: ASUS ROG Strix B650E-F Gaming WiFi (latest BIOS)

  • PSU: Seasonic Focus GX-850 V3 (850W, ATX 3.0, native 12V-2x6 cable on each GPU)

  • Primary slot: PCIe 5.0 x16 (4060 Ti)

  • Secondary slot: PCIe 4.0 x4 (PRO 4000 Blackwell)

  • OS: Windows 11 Pro 24H2, BitLocker enabled

  • Compute environment: WSL2 Ubuntu 24.04, Ollama (systemd service)

Workload at time of crash

  • Ollama serving gemma4:26b (Google Gemma 4 26B MoE, Q4_K_M quantization, ~17 GB)

  • CUDA_VISIBLE_DEVICES set to the PRO 4000’s UUID via systemd override

  • OLLAMA_CONTEXT_LENGTH=32768

  • OLLAMA_NUM_PARALLEL=2

  • Model fully loaded to GPU 1 (confirmed: ollama ps showed “100% GPU”, nvidia-smi showed 20,640 MiB / 24,467 MiB used on GPU 1)

  • Crash occurred during the first substantive generation prompt after model load (approximately 1-2 minutes into sustained inference)

Pre-crash GPU state (from nvidia-smi)

  • GPU 1 memory: 20,640 MiB / 24,467 MiB

  • GPU 1 power: climbing from 17 W idle toward rated 145 W

  • GPU 1 temperature: ~34°C at load start, rising normally

  • GPU 1 fan: ramped from 30% baseline to audibly higher (estimated 60-70%)

No thermal throttling observed prior to crash. No ECC errors reported.

Crash symptoms

  1. Fan audibly ramped to high speed (estimated 80%+)

  2. Response generation stopped mid-output

  3. nvidia-smi output:

   Unable to determine the device handle for GPU1: 0000:05:00.0: GPU is lost.
   Reboot the system to recover this GPU

  1. GPU 0 (RTX 4060 Ti) remained fully functional throughout

  2. System itself remained responsive, displays continued working

  3. Soft reboot did NOT recover the PRO 4000

  4. Full PSU power cycle (switch off, 30-second drain, switch on) required to re-enumerate the card

Reproducibility

[Fill in based on your testing — adjust as you verify:]

  • First occurrence: first substantive LLM inference workload after successful install

  • [Update: crashed again after N minutes on M attempts, OR has not yet been retested]

Bug report file

[If on Windows, nvidia-bug-report tooling is different than Linux. You can attach:

  • Windows Event Viewer logs (Event Viewer → Windows Logs → System, filter by source: nvlddmkm)

  • Output of Get-WinEvent -LogName System | Where-Object {$_.ProviderName -like "*nvlddmkm*"} from PowerShell

  • nvidia-smi output before/after crash (include timestamps)]

Additional notes

Card was in use for approximately 15 minutes total before this crash. System was installed, drivers clean-installed via NVIDIA App → standalone Studio Driver installer, and verified working with test workloads prior to first model inference. No overclocking, no custom fan curves, stock settings throughout.

The crash pattern (fan ramp → hard GPU loss → requires power cycle) exactly matches the behavior described in the Linux Xid 62/154 threads, suggesting the same underlying GSP/PMU firmware issue affects Windows drivers as well.

4

Hey @matt514, welcome aboard, and thanks for putting together one of the cleaner first posts I’ve seen in a while.

You’ve already done most of the diagnostic legwork. The crash signature you’re describing (fan ramp to ~80%, hard GPU loss, only recoverable via PSU power cycle, no ECC errors pre-crash) is the same GSP firmware pattern being tracked in the threads you cited. You’re not chasing a one-off here, you’re seeing a known cluster.

Heads up though, this post is currently sitting in the TensorRT subforum and the issue isn’t really TensorRT-related. I’m going to move it to the right place so the driver folks see it.

Thanks,
Atharva