Skip to content

Cistub Waiting for Already Running Instance to Finish

The agent log on a client repeats the same entry and no packages install:

Cistub : Waiting for already running instance to finish

The device still checks in and looks healthy in the console, but its jobs never complete. New packages queue up behind the stalled one. Restarting the agent service does not help, and the message returns after a reboot if the same package runs again.

Cistub is the CapaInstaller Agent Service. It runs one job at a time on a client, so it waits for the running instance before it starts the next one. The message is the agent behaving correctly — the problem is the job it is waiting for, which never ends.

A job hangs for one of two reasons:

  • An install script crashed without returning an exit code. The agent has no result to act on, so it keeps waiting for a process that is no longer going anywhere.
  • An installer is waiting for input that nobody can give. An MSI or EXE started without the correct silent parameters shows a dialog. The job runs in system context, where no user sees the dialog, so the installer waits indefinitely.

The second cause is the common one. It often appears right after a new package is released, or after an installer vendor changes its command-line switches between versions.

Open the client’s agent log in %ProgramFiles%\CapaInstaller\Client\Logs. Look for the last job that started and never logged a result. That package is the one blocking the queue.

The per-package logs in %ProgramFiles%\CapaInstaller\Client\Logs\Advanced show how far the package got before it stopped.

  1. In the CapaInstaller Console, open the affected unit and find the failing package in its package list.
  2. Right-click the package.
  3. Select Installed to set its status, or Unlink to remove the package from the unit.

Set it to Installed when the unit should keep the package and you are going to redeploy a corrected version. Unlink it when the unit should not have the package at all.

On the client, open Task Manager and find the script process behind the job:

  • wscript.exe or cscript.exe for a VBScript package
  • powershell.exe for a PowerShell package

Look for the one that started when the job started and is using no CPU. End it.

The script process is the one the agent waits for. If the installer it launched is also still running, for example msiexec.exe or a vendor setup, end that as well.

Restart the CapaInstaller Agent Service on the client. The agent then continues with the rest of the queue.

Steps 2 to 4 clear one device. The package hangs again the next time it runs, here or elsewhere, so correct it before you deploy it again.

Test the installer command line manually on a test device before you put it back into production.

  • Run it in system context, not as your own user. A command that installs correctly in an interactive session can still show a dialog under SYSTEM. This is the check that catches most of these.
  • Verify the silent parameters against the vendor’s current documentation. Confirm the switches for the exact version you are deploying.
  • Make the script return an exit code on every path, including its error handling. A script that exits without a code leaves the agent with nothing to act on.

The package now completes and reports a result, and the Waiting for already running instance to finish entries stop.

  • The message on its own is not an error. Seeing it once while another package installs is normal. It matters when it repeats and nothing else progresses.
  • One hung job blocks every later job on that device. A device that seems to be ignoring all its packages is often waiting behind a single bad one.
  • Check whether other devices show the same pattern. If they do, the package is at fault. If only one device is affected, look at that device — see CapaInstaller Agent Stops Working.