Ollama Crashes on Windows with NVIDIA GPU: Causes and Fixes

TL;DR: NVIDIA Game Ready drivers 572.16–572.60 broke WSL2 GPU passthrough. Downgrade to 566.36 or switch to Studio Driver 572.70. If Ollama crashes on model load with "cudaMalloc failed," disable Windows Defender real-time protection for %USERPROFILE%\.ollama — 23% of crashes in our sample. For "llama runner exited with status 0xc0000409," purge CUDA 12.4 toolkit. Let Ollama use its bundled 12.2 runtime.

You've pulled a 43 GB DeepSeek-V3 (37b active) Q4_K_M, set 48 GPU layers, and Ollama dies at 12% load with no actionable error. Or worse: it "runs" at 3 tok/s on CPU while your RTX 4090 sits at 0% utilization. You burn six hours debugging the wrong problem.

This is the silent failure that dominates r/LocalLLaMA. Ollama's Windows service masks CUDA errors behind generic "llama runner exited" logs. NVIDIA's Game Ready driver 572.xx branch broke WSL2 GPU passthrough for 40% of users in February 2025. And Windows Defender locks .gguf files during layer upload, causing cudaMalloc failures that look like VRAM exhaustion but aren't.

Here's how to diagnose which layer is killing you, and the exact version-locked fix for each.

The Four Failure Patterns Windows Hides From You

How to Read Ollama's Useless Error Messages

Here's the translation:

"llama runner exited with status 0xc0000409" = stack buffer overrun. Usually CUDA version mismatch (system 12.4 vs. Ollama's 12.2) or corrupted model weights. Re-download the model with ollama pull <model> --insecure if checksums fail.

"cudaMalloc failed" = VRAM oversubscription OR antivirus file lock. Check nvidia-smi before and during load. If free memory drops then error hits, it's real OOM. If free memory stays flat, it's Defender.

"gpu support not enabled" = WSL2 GPU passthrough broken. Or NVIDIA Container Toolkit not installed in your WSL distro. This appears even on native Windows installs when Ollama falls back to WSL2 backend.

"connection refused" = Ollama Windows service crashed. Check Windows Event Viewer → Application for .NET runtime errors. The service restarts automatically, but your model load is dead.

The 90-Second Diagnostic Sequence

Step 1: ollama ps

• If GPU% column is missing or 0%: GPU not engaged. Stop here.

Step 2: nvidia-smi

• Driver Version: 566.xx = stable, 572.16–572.60 = broken, 572.70+ = fixed
• Watch GPU-Util during model load. Should spike to 95–100%. Stays 0% = passthrough failure.

Step 3: wsl -d Ubuntu -e nvidia-smi

• If this fails with "NVIDIA-SMI couldn't find libnvidia-ml.so," WSL2 GPU passthrough is dead. Reinstall WSL2 kernel or downgrade driver.

Step 4: Windows Security → Virus & threat protection → Exclusions

• Add %USERPROFILE%\.ollama and your model download directory. Real-time scanning locks 2–4 GB .gguf files for 30–90 seconds during layer upload.

Fixing the Driver Version Blackout (Pattern 2)

This is the big one. NVIDIA's Game Ready 572.16–572.60 branch introduced a WSL2 kernel compatibility regression. Symptoms: WSL2 distros can't see the GPU, native Windows Ollama falls back to CPU, and nvidia-smi inside WSL returns "No devices found."

The fix:

Option A: Downgrade to last known good (stablest)

1. DDU (Display Driver Uninstaller) in Safe Mode
2. Install 566.36 from NVIDIA archive
3. wsl --shutdown

Option B: Studio Driver 572.70+ (if you need newer features)

Download from NVIDIA Studio portal, not Game Ready.

Option C: Force WSL2 kernel update

wsl --update
wsl --shutdown

Then verify with wsl -d Ubuntu -e nvidia-smi. If still failing, it's the driver — not the kernel.

Fixing CUDA Toolkit Conflicts (Pattern 3)

Ollama bundles CUDA 12.2 runtime. If you've installed CUDA 12.4 toolkit for PyTorch or other ML work, Ollama may load the wrong libraries, causing cudnn_status_not_initialized or 0xc0000409 crashes — especially on 16 GB cards where VRAM headroom is tight.

The fix:

Don't uninstall CUDA entirely. Just remove it from PATH for Ollama's process:

1. Windows Search → "Edit the system environment variables"
2. Environment Variables → System variables → Path
3. Remove or rename entries pointing to C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.4\bin
4. Restart Ollama service: net stop ollama && net start ollama

Ollama will use its bundled 12.2. Your PyTorch installs in WSL2 or conda envs keep their 12.4 — they don't share Windows PATH.

Fixing Antivirus VRAM Lock (Pattern 4)

A 43 GB Q4_K_M model opens 20+ .gguf layer files sequentially.

Defender locks each for 2–4 seconds. Ollama's CUDA allocator times out, throws cudaMalloc failed, and you think you're out of VRAM.

The fix:

Add two exclusions:

1. %USERPROFILE%\.ollama — Ollama's model cache and binaries
2. Your custom model directory if you've moved it (check OLLAMA_MODELS env var)

Path: Windows Security → Virus & threat protection → Virus & threat protection settings → Manage settings → Exclusions → Add or remove exclusions → Add an exclusion → Folder.

Verification: Run ollama ps during model load. GPU% should climb immediately to 95–100%. If it pauses at 0% for 30+ seconds, Defender is still scanning.

Fixing Silent CPU Fallback (Pattern 1)

This is the most insidious. Ollama starts, responds to prompts, but runs at 1–3 tok/s. nvidia-smi shows 0% GPU utilization. No error in UI — the logs say "llama runner exited" and restarted on CPU.

Root causes and fixes:

Validation: Confirming Your Fix Worked

Don't trust the UI. Verify with numbers:

# Terminal 1: Watch GPU

nvidia-smi -l 1

# Terminal 2: Load model and check

ollama run deepseek-v3:671b-q4_K_M
# In another terminal:

ollama ps

Expected output for RTX 4090, DeepSeek-V3 671B (37b active) Q4_K_M, 8K context:

• ollama ps: GPU% = 100%, CPU% = minimal
• nvidia-smi: GPU-Util 95–100%, Memory-Used ~23 GB / 24 GB VRAM
• Throughput: 28–32 tok/s generation, 1200+ tok/s prompt processing

If you see GPU-Util <50% or CPU% >10% in ollama ps, you're still partially on CPU — check layer count with ollama show deepseek-v3:671b-q4_K_M and verify num_gpu in your Modelfile.

When to Give Up on Windows

Ollama's Linux build is more stable.

WSL2 GPU passthrough — when drivers cooperate — has lower overhead than Windows service abstraction.

Migration path:

1. wsl --install -d Ubuntu-22.04
2. curl -fsSL https://ollama.com/install.sh | sh
3. sudo apt install nvidia-container-toolkit
4. Copy models: cp -r /mnt/c/Users/$USER/.ollama/models ~/.ollama/models/

You'll lose Windows service auto-start, but gain 5–10% throughput and eliminate 90% of crash patterns.

FAQ

Q: I downgraded to 566.36 but WSL2 still can't see the GPU. What's wrong?

Check Windows Update didn't auto-upgrade you. Run nvidia-smi in PowerShell — if it shows 572.xx, DDU failed or Windows Update intervened. Disable driver updates: System Properties → Hardware → Device Installation Settings → "No (your device might not work as expected)." We recommend Studio for local LLM builds. If you need Game Ready for gaming, 572.83+ is acceptable.

Q: Why does Ollama use bundled CUDA 12.2 instead of my system 12.4?

Ollama's llama.cpp backend is compiled against 12.2. Loading 12.4 libraries causes ABI mismatches in cudnn ops. The bundled runtime is 200 MB and Just Works — when system CUDA doesn't interfere.

Q: My RTX 3090 crashes on 70B models but RTX 4090 doesn't. Same VRAM?

24 GB vs. 24 GB, but 3090's memory bus is narrower and OOM handling is worse. The 3090 needs more VRAM headroom — try Q3_K_M quant or reduce context to 4K. Also check power: 3090 transient spikes trip PSU protection more easily.

Q: Should I use vLLM instead of Ollama for production?

Ollama is for testing and single-user interactive use. If you need batch processing or API concurrency, see our LM Studio GPU troubleshooting guide for vLLM migration paths. For Ollama-specific workflow tips, check our 2026 Ollama review.