wslcontainers
Ask AI wslc 2.9.4.0

wslc GPU not working: NVIDIA and AMD fixes

Updated 2026-07-27 · 7 min read · wslc public preview

GPU access on wslc works through the --gpus flag, the same one Docker uses. But because wslc is young, there are a few sharp edges. This page covers the known failure modes, each one traced to a real issue in the microsoft/WSL repository.

## The core rule: --gpus works, --device does not | Flag | wslc 2.9.4.0 | Behaviour | |---|---|---| | --gpus all | ✅ Supported | Passes all GPUs via CDI, same as Docker | | --gpus '"device=0"' | ✅ Supported | Select a specific GPU | | --device | ❌ Rejected | "Argument name was not recognized" | | /dev/kfd (AMD) | ❌ Missing | ROCm passthrough blocked | ## NVIDIA: "Stale file handle" and invalid nvidia-smi Users on wslc 2.9.4.0 report that after a driver update, the container sees /usr/lib/wsl/lib as a Stale file handle and nvidia-smi reports no usable devices. This is tracked as microsoft/WSL #41050 (GTX 1080 Ti ×3, NVIDIA driver 582.66, WSL 2.9.3.0). **The fix sequence that clears it:** 1. Restart the subsystem — a stale handle usually means the session VM outlived a driver or WSL update: ```powershell wsl --shutdown ``` 2. Update the Windows NVIDIA driver — the WSL user-mode driver ships with the Windows driver, so an old host driver breaks CUDA even when the flag is correct. 3. Verify the mapping inside the container: ```powershell wslc run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi ``` 4. If /dev/dxg is missing, the passthrough did not apply — check wslc exec <id> ls -l /dev/dxg. ## AMD: ROCm needs /dev/kfd, and wslc has no --device AMD GPUs (e.g. Radeon 9070 XT with ROCm 7.2) want two things wslc does not yet provide: the /dev/kfd device mapping and the --device flag. This blocks ROCm workloads like ComfyUI / PyTorch-ROCm. Tracked as microsoft/WSL #40988. **Status:** the feature is acknowledged; there is no workaround using current flags. If you need ROCm today, run the container on Docker Desktop or a native Linux host. ## ldconfig failed with status 0x100 You run --gpus all on a machine with no GPU and the container fails at start with an ldconfig failed with status 0x100 hook error. This is not a bug — it is wslc correctly reporting that the host has no GPU to pass. On GPU-less hosts (most CI runners), drop --gpus entirely. ## Fast diagnostic ```powershell # 1. is wslc seeing the GPU at all? wslc run --rm --gpus all nvidia/cuda:12.4-base nvidia-smi # 2. is the CDI device present inside? wslc run --rm --gpus all nvidia/cuda:12.4-base sh -c "ls -l /dev/dxg" # 3. on a GPU-less host, confirm the failure is expected: wslc run --rm alpine echo "no gpu, no problem" ``` For any GPU error you cannot resolve here, paste the output into the error diagnostic — it is grounded on these exact failure modes.

Related guides