Llama Runner Process Has Terminated: Ollama Exit Codes

The phrase you searched is a wrapper, not a cause. Ollama assembles this message in llm/llama_server.go as llama-server process has terminated: EXIT STATUS: LAST CAPTURED ERROR LINE, so the whole diagnosis lives in the two fields after the first colon. Read the exit status first, because the three kinds are unrelated: a Windows hex code like 0xc0000409 is an NTSTATUS the operating system assigned and names a specific crash; a signal like signal: killed means something outside the process ended it; and a plain exit status 2 means nothing at all beyond "the process returned 2". If nothing follows your exit code, that absence is itself the clue — Ollama only captures stderr lines that match a fixed prefix list, and the line that actually killed your run is sitting unmatched in the server log.

This is, by a wide margin, the most-reported failure in the Ollama tracker. A GitHub issue search of ollama/ollama run on 23 August 2026 returned 111 issues with the phrase in the title and 570 mentioning it anywhere. Almost none of them share a root cause. That is why generic "fix Ollama" advice bounces off this error: the phrase is the same for a missing DLL on Windows, a Metal assertion on an M5, and a 671B model on a laptop.

Everything below is read from Ollama's own source on main and from the linked issue threads. Where a number appears, it is either a count from that search or a piece of arithmetic shown in full.

What is Ollama actually telling you

Here is the construction, from llm/llama_server.go on main:

if s.cmd != nil && s.cmd.ProcessState != nil && s.cmd.ProcessState.ExitCode() >= 0 {
    return fmt.Errorf("llama-server process has terminated: %s: %s", ExitStatus(s.cmd.ProcessState.ExitCode()), msg)
}

Three fields, and each one answers a different question:

1. The fixed phrase. Ollama's Go parent process launched a child (llama-server), the child died before it started answering health checks, and the parent gave up. That is all the phrase means. It is not a model problem, a network problem or a corrupt download by itself.
2. The exit status. How the child died. This is the field the rest of this page is about.
3. The tail. msg is s.lastErrMsg() — the most recent stderr line the child printed that matched Ollama's error-prefix filter. When present, this is nearly always the real answer.

There are four sibling branches in that same function. If the process died from a signal rather than an exit code, ProcessState.ExitCode() returns -1 (that is the documented behaviour of Go's os.ProcessState.ExitCode: it returns -1 "if the process hasn't exited or was terminated by a signal"), the status is treated as unknown, and Ollama falls through to wrapping Go's raw error instead — which is why signal deaths render as signal: killed and signal: aborted (core dumped) rather than as a number.

Which exit code do you have

Counts in the fourth column are issues with that string in the title, from the same 23 August 2026 search. They are a rough measure of how often each one bites, not a severity ranking, and they will drift.

Two rows deserve a warning label:

• exit status 2 is the largest bucket and the least informative. The reports behind it have nothing in common: #11527 is a portable Windows install where the Microsoft VC++ redistributable was never installed with admin rights (the reporter pinned the failure to "the point where the C++ function ggml_load_all_from_path is called via cgo"); #16116 is Gemma 4 failing on an Apple M5 while Gemma 3 works; #16102 is Qwen2.5 14B on a Maxwell GTX TITAN X where the 7B of the same family loads fine. Same code, three unrelated bugs.
• GGML_ASSERT is not one failure either, which is why its count is the biggest here. GGML_ASSERT(n_inputs < GGML_SCHED_MAX_SPLIT_INPUTS) failed on Gemma 4 (#16506) and GGML_ASSERT(a->ne[2]*4==b->ne[0]) on GLM-OCR (#16696, where the reporter's stated root cause is the default 4096 context being too small for the image's vision tokens) share only the word ASSERT. Copy the assertion text — parentheses and all — into the tracker search.

Why is the code hex on Windows and a plain number on Linux and macOS

Because Ollama formats it differently per platform, and the split is small enough to read in full. llm/exit_status_windows.go does this:

const (
    ntstatusSeverityMask  = 0xc0000000
    ntstatusSeverityError = 0xc0000000
)

raw := uint32(s)
if raw&ntstatusSeverityMask != ntstatusSeverityError {
    return decimalExitStatus(s)
}
return fmt.Sprintf("exit status 0x%08x: %s", raw, windows.NTStatus(raw).Error())

The non-Windows file is one line long: it always returns the decimal form. So the hex is not cosmetic. Ollama masks the top two bits of the exit code and only switches to hex when Windows set the NTSTATUS severity bits to "error" — that is, when the operating system terminated the process rather than the process choosing to exit. A hex code is therefore strictly more informative than a decimal one: it tells you the OS did the killing, and the name that follows it comes from Windows itself, not from Ollama.

That trailing text is generated by NTStatus.Error() in golang.org/x/sys/windows, which calls FormatMessage against ntdll. This explains an odd log line that turns up in these reports. Issue #17375 (RTX 4060 Laptop, Ollama 0.32.3, Windows 11) records:

failure during llama-server GPU discovery
error="llama-server --list-devices failed: exit status 0xc0000005: The instruction at 0xp referenced memory at 0xp. The memory could not be s."
inference compute id=cpu library=cpu

The literal 0xp placeholders are not corruption — FormatMessage is called with FORMAT_MESSAGE_ARGUMENT_ARRAY and no argument array, so Windows' own message template is never filled in. More usefully, look at the last line: this crash happened during GPU discovery, so Ollama did not fail at all. It fell back to CPU and kept running. If your symptom is "Ollama is suddenly slow" rather than "Ollama crashed", that is the same bug wearing different clothes, and our guide to why Ollama silently runs on the CPU picks up from there.

Two more Windows hex codes worth naming, both from the NTSTATUS registry documented in MS-ERREF NTSTATUS Values: 0xc000001d is an illegal instruction, and in #7266 it fires on every model on a Snapdragon 8cx Gen 3 Windows-on-ARM box, which is an architecture mismatch rather than anything model-specific. 0xc0000135 is a missing DLL, reported in #6554 by someone wiring Ollama to Intel's IPEX-LLM backend. If you are setting Ollama up on Windows in the first place, the Ollama Windows installation guide covers the runtime dependencies that produce both of these.

Why is there nothing after your exit code

This is the question the tracker never answers, and it has a precise answer in the source.

Ollama does not log every stderr line the runner prints into the error. It runs each line through a filter in llm/status.go and keeps only the ones that contain a known prefix. This is the entire list, verbatim from main:

var errorPrefixes = []string{
	"mlx:",
	"MLX:",
	"panic:",
	"fatal error:",
	"error:",
	"Error:",
	"CUDA error",
	"ROCm error",
	"cudaMalloc failed",
	"\"ERR\"",
	"error loading model",
	"GGML_ASSERT",
	"Deepseek2 does not support K-shift",
	"signal arrived during cgo execution",
	"llama_init_from_model:",
}

If the line that killed your runner does not contain one of those fifteen strings, it never reaches your terminal. You get a bare exit code and no tail, and the actual cause is sitting in the server log where nothing pointed you.

That is not a theory. The clearest worked example is exit status 127. In #7542, a commenter on Ollama 0.4.0 posted the journal around the crash, and the two consecutive lines are:

/tmp/ollama3255965013/runners/cuda_v12/ollama_llama_server: error while loading shared libraries: libggml_cuda_v12.so: cannot open shared object file: No such file or directory
level=ERROR source=sched.go:455 msg="error loading llama server" error="llama runner process has terminated: exit status 127"

The cause is right there — the dynamic linker could not find a bundled library — and it is invisible to the user, because "error while loading shared libraries" is not in the prefix list. The maintainers know: directly above that list, the source carries a standing TODO reading "regex matching to detect errors like libcublasLt.so.11: cannot open shared object file". (The specific regression in #7542 was closed as fixed by PR #7560, but the reporting gap it exposes is still open.)

There is a second filter worth knowing about, because it can make this error disappear entirely. status.go also carries an out-of-memory substring list — out of memory, out of device memory, cudaMalloc failed, hipMalloc failed, failed to allocate, allocation failed, not enough memory, insufficient memory, vk_error_out_of_device_memory, erroroutofmemory — and when a matching line appears during startup, llama_server.go returns a different message: llama-server reported out-of-memory during startup. So a memory failure on a recent build may not say "process has terminated" at all. If you are seeing that phrasing, you already have your answer, and the fix is sizing rather than debugging: our Ollama model RAM and VRAM table lists what each model actually needs.

Where is the log line that came just before the crash

The tail Ollama prints is one line. The log has the rest. From the official Ollama troubleshooting docs:

# macOS
cat ~/.ollama/logs/server.log

# Linux with systemd
journalctl -u ollama --no-pager --follow --pager-end

# Docker
docker logs <container-name>

On Windows the docs point you at explorer %LOCALAPPDATA%\Ollama, where the current log is server.log and rotated ones are server-#.log. To get more detail, quit the tray app first, then relaunch it from PowerShell with $env:OLLAMA_DEBUG="1".

What you are scrolling for is the launch line and everything between it and the failure. This is the real shape of it, from #16506 on Ollama 0.30.4 under WSL2:

source=llama_server.go:403 msg="starting llama-server" cmd="/usr/local/lib/ollama/llama-server --model .../blobs/sha256-4e30e26652... --port 45661 --host 127.0.0.1 --no-webui --offline -c 4096 -np 1 ..."
source=sched.go:613 msg="system memory" total="13.5 GiB" free="9.6 GiB" free_swap="48.0 GiB"
source=sched.go:620 msg="gpu memory" id=0 library=CUDA available="2.8 GiB" free="3.2 GiB" minimum="457.0 MiB" overhead="0 B"
source=llama_server.go:1131 msg="waiting for llama-server to start responding"
source=llama_server.go:1186 msg="waiting for llama-server to become available" status="llm server not responding"

Three things in that block are worth more than the error message itself:

• The full cmd= line is the exact command Ollama ran. Copy it and run it by hand in a terminal — the runner's unfiltered stderr goes straight to your screen, prefix list bypassed. This is the single fastest way to see what the filter swallowed.
• The -c value is the context length actually used. In that log it is 4096, and #16696 is an example of a crash whose root cause was exactly this number being too low for the input.
• system memory and gpu memory are Ollama's own view of what was free at launch. If available is a fraction of the model size, you are looking at a sizing problem, not a bug — the Ollama system requirements guide covers the headroom each tier needs.

That signal: killed row in the table is the purest sizing case. SIGKILL cannot be raised by a process on itself, so the kernel or another process ended it. Both tracker reports are the same shape: #8571 is deepseek-r1:671b on 64GB and 128GB Macs, and #8464 is DeepSeek-v3 on a 128GB M4 Max whose reporter reasoned that Q4 on 128GB "should be enough". Do the arithmetic instead: 671 billion weights at roughly 4.5 bits each is 671 × 4.5 / 8 ≈ 377 GB of weights before any KV cache, which is about three times a 128GB machine. On Linux, confirm it with dmesg or journalctl -k and look for the kernel OOM killer naming the process.

Why does yours say llama-server when everyone else says llama runner

Because Ollama renamed the child process, and both spellings are alive in search results.

The string in the source today is llama-server process has terminated. Reports on Ollama 0.16.2 in February 2026 still show llama runner process has terminated (#14291), while reports on 0.30.4 and 0.31.1 show the new wording (#16506, #17012). They are the same failure and the same code path — only the label moved. When you search the tracker, search both.

You may also see it wrapped as Error: 500 Internal Server Error: llama-server process has terminated: .... That happens when the request came through the HTTP API rather than the CLI. The 500 is transport, not diagnosis; ignore it and read what follows.

Three real reports read end to end

Same error string, three genuinely different bugs, each linked so you can check whether it has been fixed since.

The pattern across all three: the hex code was identical and irrelevant, and the line after it was the whole answer. Two of them are AMD or NVIDIA driver problems that no Ollama setting can fix.

If none of the codes in the table match yours, work through the broader Ollama troubleshooting guide, which covers the failures that never reach the runner at all — pulls, ports, permissions and the API layer. For crashes that only appear once a second card is in the box, the Ollama multi-GPU setup guide covers device ordering and split behaviour, which is its own family of load failures.

What this page cannot tell you

• We do not own the hardware in these reports. Every code, log line and error string above is quoted from the linked GitHub issues or read from Ollama's source on main. Nothing here is a reproduction on our own machines, and we are not going to claim one on a Strix Halo or an M5 we do not have.
• The counts move. 111 in-title issues and the per-code numbers come from one GitHub search on 23 August 2026. Re-run the search rather than trusting the figure a year from now.
• The prefix list is a snapshot. errorPrefixes in llm/status.go has been edited repeatedly. Open the file on main before concluding that your log line is unmatched.
• Some codes in the tracker are not in this table on purpose. Rows here are limited to strings with real, countable report volume. Inventing a plausible-looking code would make the table worse, not longer.
• A closed issue is not a fixed machine. Several of the reports above were closed by an Ollama release. If your version predates the fix, upgrading is the change that matters, not the workaround in the thread.

FAQ

What does "llama runner process has terminated" mean in Ollama

It means Ollama's Go parent process launched the llama-server child, the child died before it responded to a health check, and the parent surfaced that as an error. The phrase itself carries no diagnosis. The exit status and the captured stderr line that follow it do.

Is "exit status 2" a memory problem

Usually not, and there is no way to tell from the code alone. Ollama has a dedicated out-of-memory path — a matching line makes it report llama-server reported out-of-memory during startup instead. A bare exit status 2 is a plain non-zero exit with no OS-assigned meaning; the linked reports behind it include a missing Microsoft VC++ runtime, an Apple M5 backend crash and a Maxwell-era CUDA failure.

Why does my error end at the exit code with nothing after it

Because the fatal line did not match Ollama's error-prefix filter in llm/status.go, so it was never captured. The line still exists in the server log. The fastest way to see it is to copy the full cmd= string from the starting llama-server log entry and run that command by hand — the runner's raw stderr then goes straight to your terminal.

What is exit status 0xc0000409 in Ollama

It is the Windows NTSTATUS for a stack buffer overrun, printed in hex because Ollama only uses hex when Windows set the NTSTATUS error-severity bits — meaning the OS terminated the process. In the tracker it repeatedly accompanies a GPU backend line: CUDA error: shared object initialization failed in #17627, ROCm error: unspecified launch failure in #16734, and a PTX toolchain mismatch in #17012. Read that second line, not the code.

Ollama says "signal: killed" — how do I fix it

You cannot fix it inside Ollama. SIGKILL comes from outside the process, and in both tracker reports the model simply did not fit: a 671B model at roughly 4.5 bits per weight needs 671 × 4.5 / 8 ≈ 377 GB for weights alone. Check dmesg on Linux for the kernel OOM killer, then pick a model that fits the machine.

Does reinstalling Ollama fix this

Only for the dependency-shaped codes. 0xc0000135 (missing DLL) and exit status 127 (dynamic linker failure) are exactly the cases where a clean reinstall replaces what is missing. For assertion failures, driver mismatches and out-of-memory conditions, reinstalling changes nothing and costs you your model downloads.

Sources

• ollama/ollama — llm/llama_server.go (error construction and the out-of-memory branch, main)
• ollama/ollama — llm/status.go (errorPrefixes, the out-of-memory substring list, and the standing TODO)
• ollama/ollama — llm/exit_status_windows.go (the NTSTATUS severity mask and hex formatting)
• Ollama — official troubleshooting docs (log locations per platform, OLLAMA_DEBUG)
• Go — os.ProcessState.ExitCode (returns -1 when the process was terminated by a signal)
• Microsoft — MS-ERREF NTSTATUS Values (the canonical registry for the 0xc0000xxx codes)
• ollama/ollama issues #6554, #7266, #7542, #8464, #8571, #11527, #14291, #16102, #16116, #16506, #16696, #16734, #17012, #17375, #17627