If you run local LLMs on Windows with an NVIDIA GPU, you've probably seen LM Studio's "runtime extension packs." They're the bundled CUDA/ROCm/Vulkan builds of llama.cpp that actually run your models. And by default, LM Studio auto-updates them in the background.
That bit me on an RTX 5090. One day a model that had loaded fine for days suddenly refused to load. The dialog just said:
Failed to load the model / Error loading model. / (Exit code: 18446744072635812000). Unknown error. Try a different model and/or config.
No hint of what the number meant. No hint of what broke. The model file was untouched, config untouched, driver untouched. The only thing that changed was the runtime.
The exit code is a Windows NTSTATUS, not a random number
That huge unsigned value isn't a random roll of the dice. Convert it to hex and you get 0xFFFF_FFFF_C000_08A0 — a sign-extended NTSTATUS. The low 32 bits, 0xC00008A0, are the actual error status.
NTSTATUS values are how Windows reports driver and kernel-level failures. The UI doesn't translate them, so you get a wall of digits. If you ever see a giant unsigned exit code like this in a local-LLM tool, convert it to hex and check the low 32 bits. That tells you you're dealing with a driver/CUDA-level failure, not something wrong with your model file.
The real error was hiding in the logs
The dialog didn't tell me anything useful, but LM Studio's Developer > Local Server logs did. There I found the actual CUDA error: CUDA error: shared object initialization failed in launch_fattn (the flash-attention kernel), with the model's Gated Delta Net fallback path logged as unsupported and disabled. The runtime was crashing in a specific kernel on the Blackwell architecture.
Cross-referencing the upstream llama.cpp issue tracker confirmed it: the CUDA 12 runtime v2.27.1 has a broken fallback path on RTX 5090 (sm_120). It's not your model. It's not your config. It's the runtime build.
The fix: roll back the runtime pack
LM Studio runtime extension packs are versioned, and you can pin an older one. In LM Studio: Settings > Runtime, pick the older CUDA 12 build (v2.25.2 worked for me), and the model loads again immediately. No re-download of the model, no config changes, no driver reinstall.
While you're in there, turn off "Auto-update selected Runtime Extension Packs". It defaults to on, and it's what silently swapped in the broken build in the first place. Leave it off until the fixed runtime ships.
The general lesson
Any local-LLM tool that bundles a runtime — LM Studio, Ollama, llama.cpp servers — can silently swap that runtime on update. The failure signature to watch for:
- A model that loaded fine suddenly fails, with nothing else changed.
- A cryptic huge unsigned exit code and "Unknown error" in the UI.
- Logs that name a specific CUDA kernel or a "not supported / disabled" fallback path.
When you see that combo, don't re-download the model and don't reinstall drivers. Check the runtime version first. Roll it back, disable the auto-update, and carry on. New GPU architectures (Blackwell included) are where these runtime regressions bite hardest, because the fallback paths are new and rarely exercised until real users hit them.
If you want the full thread: lmstudio-bug-tracker issue #2234 and the upstream llama.cpp issue #26481.
