Kill Open Process (Windows)

What the named-process termination Worklet does

This Automox Worklet™ terminates one or more named processes on Windows endpoints. The remediation script reads a $processesToCheck array, walks each entry, queries Get-Process -Name <process> -ErrorAction SilentlyContinue, then iterates over every returned process object and calls Stop-Process -Id $process.Id -Force on each PID. Each match writes a status line to standard output, which Automox surfaces in the Activity Log alongside the policy run identifier.

Process names are passed without the .exe suffix to match PowerShell's process-object naming. notepad targets notepad.exe, chrome targets chrome.exe, and ms-teams targets the new Microsoft Teams client. The Worklet does not require a PID and does not depend on window titles, so it works against background services and tray-only processes that the legacy taskkill /F /IM pattern also targets but with less granular reporting.

The evaluation script always exits 0, which makes the Worklet behave as an on-demand action rather than a recurring compliance check. The Worklet is the right shape for FixNow runs, pre-install steps in a Run Policy chain, or a one-off remediation when an endpoint has a stuck process pinning a file. Change the evaluation exit code to 1 if you want recurring policy runs to call remediation on every interval.

Why terminate stuck processes from the console

Open processes are the most common reason a Windows software update fails. The installer cannot replace a locked DLL or EXE, the package manager rolls the transaction back, and the endpoint stays on the vulnerable version. Adobe Reader, Chrome, Outlook, Microsoft Teams, Zoom, and VPN clients all exhibit this pattern. The standard remote-help fix is for a technician to RDP to the endpoint and close the application by hand. A second common failure mode is the orphaned background process – a setup launcher that exits without cleaning up, a service that fails to stop on uninstall, or a tray utility that survives a logoff and prevents the next package from binding to a port.

Windows installers fail with a non-zero exit code when the application is still running, and a help desk cannot ask thousands of users to quit the app on cue. Chain this Worklet ahead of the install or upgrade Worklet for the same application: it runs Stop-Process -Force against the named process on every Windows endpoint in scope, so the upgrade policy stops requiring a per-endpoint handshake to close the running binary before the upgrade lands.

How named-process termination works

1. Evaluation phase: The evaluation script exits 0 with no comparison. The Worklet is built for on-demand execution from FixNow or a policy chain, not for a recurring compliance loop. If you need recurring remediation – for example to keep an unwanted process from coming back – swap the exit 0 line in evaluation.ps1 for exit 1, and every policy run will call the remediation step.

2. Remediation phase: The remediation script iterates over $processesToCheck. For each name it runs Get-Process -Name <name> -ErrorAction SilentlyContinue. A match triggers a per-PID loop that calls Stop-Process -Id $process.Id -Force on each returned process object, which invokes TerminateProcess and bypasses the application's normal shutdown handler. The script writes one line per process to the Activity Log: "[name] is running. Killing." on a hit, "[name] isn't running on this device." on a miss (the script string uses "device" verbatim). Any termination failure caught in the try/catch (locked process, access denied, process protected by anti-tamper) exits the remediation with code 50, which surfaces in Automox as a remediation failure rather than a silent pass.

Process termination requirements

• Windows 7, Windows 8.1, Windows 10, Windows 11, or Windows Server 2012 R2 and later. The Worklet runs on any Windows endpoint with PowerShell 5.1 or PowerShell 7.

• Administrative privileges on the endpoint. The Automox agent runs as SYSTEM by default, which satisfies the requirement for every process except those protected by PPL (Protected Process Light) such as MsMpEng.exe and lsass.exe.

• Edit remediation.ps1 to set $processesToCheck = @('chrome','notepad','outlook'). Use the PowerShell process name (no .exe suffix). To discover the right names, run Get-Process | Select-Object Name, ProcessName, MainWindowTitle on a reference endpoint and copy the Name column.

• The equivalent cmd.exe pattern – taskkill /F /IM chrome.exe – also works but does not return per-process status to the Activity Log in the same shape; the PowerShell Stop-Process path is the recommended one for this Worklet.

• Allow time in the policy for the application to flush state before chaining an installer step. Force-terminating an open editor or office app loses unsaved end user work; pair the Worklet with a notification policy during business hours.

Expected state after process termination

After the remediation runs, Get-Process -Name <name> returns no objects for any process that was on the $processesToCheck list, and Task Manager shows the corresponding row gone. The Activity Log entry for the run lists every input process with one of two outcomes: "is running. Killing." followed by silent termination, or "isn't running on this device." for entries that were never active. A trailing "Process check and termination completed." line marks a clean run. Exit code 0 indicates every termination either succeeded or was unnecessary; exit code 50 indicates at least one Stop-Process call failed and a follow-up run or a manual session is required.

Validate by re-running the Worklet immediately after the first run. The second run should report every process as "isn't running on this device." If a process is reported as running on every consecutive execution, the endpoint has a watchdog or auto-restart mechanism in place – a Windows Service set to recover on failure, a scheduled task that relaunches the binary, or a parent process that respawns its child. In those cases, chain this Worklet with a Service disable or scheduled-task removal Worklet so the watchdog stops before the child process is terminated. For audit evidence, capture the Activity Log line per process and store it with the policy run identifier; the per-process granularity is the reason to prefer this Worklet over a bulk taskkill in a script repository.