Quick answer
The IBM Datacap Rulerunner service usually stops for one of five reasons: consecutive aborted batches tripping its stop-on-abort protection, a lost connection to the Datacap Server (TMS), unbounded process memory growth, a service-account problem, or a failed dependency such as SQL Server or a batch file share. The diagnosis starts in two places — the Windows Application Event Log and the Rulerunner logs.
Rulerunner is IBM Datacap’s background processing engine. Every unattended task — ingestion, page identification, recognition, export — runs on its threads. When the Rulerunner service stops, capture stops: scan operators keep scanning, but nothing moves, nothing exports, and the batches quietly pile up. In an Intelligent Document Processing (IDP) pipeline feeding claims, loans, or invoices, that is a production outage with a delay fuse.
This page covers the five causes in order of likelihood, the exact log signatures that identify each one, and the fix for each — in full, on this page. (The complete catalog of IBM Datacap agentless tests and health checks is published here, also ungated.)
Why this page exists
IBM’s own resolution notes for the most common Rulerunner failures are real — and they sit behind a support login. The symptoms are public; the fixes are gated. What follows is the ungated version, assembled from the field.
01 — The Symptom
What you’re seeing
Match your logs to one of these signatures before touching anything.
One or more of the following, usually together: the Datacap Rulerunner Service shows stopped in Windows Services, with The Datacap Rulerunner Service service terminated unexpectedly in the Event Viewer. The Rulerunner log ends with Thread #[0] connection level exception, no more servers followed by Internal exception in main queueing. Stop_on_abort enabled. Job Monitor shows batches frozen in Running that never complete, a growing count of aborted batches, and no new batches being created. Restarting the service works — until it stops again.
That last part matters. If the service keeps stopping, the restart isn’t the fix — it’s the loop. Something upstream is killing it on a schedule, and the schedule is your batch volume.
02 — The Causes
Five causes, ranked by likelihood
Start at the top. In most estates, it’s the first one.
| # | Cause | The signature | The fix, in short |
|---|---|---|---|
| 1 | Consecutive aborted batches trip stop-on-abort | Aborted batches pile up in Job Monitor, then all threads shut down; log notes Stop_on_abort enabled | Fix what’s aborting the batches, reset them, then restart |
| 2 | Lost connection to the Datacap Server (TMS) | connection level exception, no more servers, then Internal exception in main queueing | Restore/verify TMS, restart Datacap Server first, Rulerunner second |
| 3 | Process memory growth | Rulerunner process working set climbs across the day, then the process dies with no clean error | Rebalance heavy profiles; recycle on your schedule, not Windows’ |
| 4 | Service-account problems | Runs fine from a command prompt under the same account, but dies as a service; Rulerunner Manager times out | Re-verify password, “Log on as a service” right, saved credentials |
| 5 | Dependency failure (SQL, file shares) | Timeouts against the Engine/Admin/Fingerprint databases or the batch share precede each stop | Fix the dependency; check antivirus scanning of batch folders |
Cause 1 is a design decision, not a crash. After several batches abort consecutively, Rulerunner shuts down all of its processing threads — deliberately, to stop a poison batch or a broken rule from burning through the whole queue (IBM documents the behavior). The service didn’t fail; it obeyed. Which means the real question is never “why did Rulerunner stop?” — it’s “why did those batches abort?” The usual suspects: a failing action in one task profile after a change, a corrupt or unexpected document, an export target that went away mid-run, or a database timeout inside a task.
Cause 2 is the infrastructure version of the same story. No more servers means Rulerunner ran out of Datacap Servers to talk to — the primary TMS went unreachable and no backup answered. A Datacap Server service restart, a network drop, or an authentication failure will each produce it, and with stop-on-abort enabled the queueing exception takes the whole service down with it.
Causes 3 through 5 are slower burns: recognition-heavy profiles on large batches walking the process working set upward until Windows ends it; a rotated service-account password or a Group Policy refresh that quietly removed the Log on as a service right; the Engine database or batch file share developing latency that surfaces as task failures. Each one looks random from the service’s point of view. None of them are — this is the same pattern we cataloged across capture platforms in the root causes of IDP downtime.
03 — The Fix
The repair sequence
In order. Skipping to the restart puts you back in the loop.
-
Read the two logs before touching the service
Windows Application Event Log first, then the Rulerunner logs (service-level log plus the per-batch logs in the batch directory). Match what you find to the table above. Two minutes here saves the afternoon.
-
If batches aborted: fix the cause, then reset the batches
In Job Monitor, open the log of the first aborted batch — not the last — and identify the failing task and action. Restore the export connection, pull the poison document, or roll back the rule change. Then reset the aborted batches to Pending. If you restart without fixing the cause, the next batches abort and the threads stop again.
-
If the log says “no more servers”: restore TMS, restart in order
Confirm the Datacap Server service is running and reachable from the Rulerunner host, and that any backup TMS is actually configured and answering. Then restart the Datacap Server service first and the Rulerunner service second — Rulerunner started against a dead TMS just dies again.
-
Release the batches stuck in Running
Any batch Rulerunner was holding when it died keeps its lock and sits in Running forever. Reset each one to Pending in Job Monitor once the root cause is fixed — otherwise the queue looks alive and processes nothing.
-
If memory is the killer: rebalance, and recycle on your terms
Track the Rulerunner process working set across a full processing window. If it only ever climbs, split recognition-heavy task profiles across threads or schedules, and schedule a controlled service recycle in a quiet window — a planned 60-second restart at 2 AM beats an unplanned one at 2 PM.
-
If the service won’t start at all: it’s the account, not the software
The tell: Rulerunner runs fine from a command prompt under the same account but dies as a service. Re-enter the service-account password in the service definition, confirm the Log on as a service right survived the last Group Policy refresh, and re-save the credentials in Rulerunner Manager.
04 — Prevention
How to stop it from happening again
Every cause above broadcasts itself before the service dies.
Look back at the table: aborted batches accumulate before the threads shut down. Memory climbs before the process dies. TMS connectivity drops before the queueing exception. The reason this failure repeats in most Datacap estates isn’t that the signals don’t exist — it’s that nobody is watching them between incidents. The Windows service being “Running” tells you almost nothing; Rulerunner can be up while every batch it touches aborts.
This is where observability earns its keep. Reveille for IBM Datacap ships over 50 out-of-the-box agentless tests, and the ones that matter for this exact failure chain are pre-configured: Windows Event Log for Rulerunner service errors, RuleRunner Process Count, RuleRunner Process Memory Usage and RuleRunner Executable Memory Usage, Batch Aborted Count, Unprocessed Batches, and Datacap Batch Aging for all batches older than 48 hours — plus connectivity checks that the TaskMaster Rulerunner Server can be pinged and the TaskMaster services are genuinely responding, not just present in the services list. Wire those to alerts and the sequence in section 03 becomes something you run on a warning, not on an outage. If you’d rather see it than read it, you can try Reveille against a sample estate.
Reveille for IBM Datacap
Agentless tests for Rulerunner health, batch aging, aborts, and TMS connectivity — with dashboards for capture throughput and over 50 IBM Datacap dashboard metrics. The full test catalog is linked above, ungated.
Take it with you
Fighting Rulerunner this week?
Enter your business email and the Reveille — IBM Datacap Monitoring Test List opens as a PDF: over 50 pre-configured, agentless tests organized by category — including every Rulerunner, batch-aging, and TMS check on this page — formatted as a checklist you can run by hand.
Everything in the PDF is also published free on this site. The PDF is the portable copy.
Frequently asked questions
