How to Kill a Process on a Remote Windows Computer

A frozen application on your own machine is a nuisance. But a stalled application on a server three floors down or at a distant branch office is a different problem. Opening a full remote desktop session just to reach Task Manager doesn’t sound smart. So, what should you do?

There are three ways to terminate a process on a remote Windows computer:

• taskkill: To terminate a process on a remote Windows computer without starting a PowerShell remoting session, use taskkill. It is built into Windows and supports remote computers with /s.
• Invoke-Command: If you already use PowerShell remoting, Invoke-Command gives you more control and makes it easier to automate the operation.
• PsExec: PsExec is another option for running a command remotely, but it adds an external tool and its own service and firewall requirements.

Each method has different prerequisites, credential handling, and failure modes. The following table presents a quick comparison:

Firewall requirements depend on the Windows configuration and network policy. Test connectivity from the administration workstation to the target to verify that the required network path is available.

Pro Tip: Before using any of these methods, you must identify the target, i.e., the exact process you want to terminate. tasklist /s remotecomputer lists every process running on the remote machine with its process ID and image name. You can also supply /u and /p when you need to use specific credentials.

Method 1: Kill a Remote Process with taskkill

taskkill is built into Windows and doesn’t require installing another tool or enabling PowerShell remoting, but remote use still depends on network connectivity, authentication, sufficient permissions, and the target system’s remote administration settings. To end one or more processes on a remote machine with a single command, it’s the simplest method.

To use taskkill, you need to know the remote target’s name or IP address and hold administrative rights on it. The command ends processes by Process ID or by image name. The /s flag makes it remote. For example:

taskkill /s FILESRV01 /pid 1234

Replace FILESRV01 with the remote computer name and 1234 with the process ID. Run this from Command Prompt or PowerShell. It runs under your current account unless you supply /u to use a different one.

Remote taskkill Syntax

The command syntax is as follows:

taskkill [/s <computer> [/u [<domain>\]<username> [/p [<password>]]]]
 {[/fi <filter>] [...] [/pid <processID> | /im <imagename>]} [/f] [/t]

Note the following:

• Everything in square brackets is optional, and the parameters can appear in any order.
• Specify the process with /pid or /im, or narrow it down with a /fi filter. You can repeat /pid or /im to end several processes in one command.
• If you provide credentials with /u, the /s flag becomes mandatory.
• /fi lets you narrow down the process or processes you want to stop.

Remote taskkill Parameters and What They Do

taskkill has the following parameters:

Remember:

• taskkill /s takes a computer name or IP address without the backslash, for example, taskkill /s FILESRV01. PsExec, on the other hand, requires the backslash (\\FILESRV01). Mixing them up is a common cause of first-attempt failures.
• You must specify at least one target using /pid, /im, or a /fi filter. Otherwise, the command returns an error.

Which taskkill Filters Work on Remote Computers?

Here are the filters you can use with taskkill:

The following is an example of applying a filter to terminate every remote process over a certain memory threshold:

taskkill /s FILESRV01 /f /fi "MEMUSAGE gt 500000" /im *

This forcefully terminates every process on FILESRV01 that’s using more than 500,000 KB (roughly 500 MB) of memory. Be careful with this one. On a production server, that can include your database engine or other critical services, so run the same filter with tasklist first.

Perform a Dry Run

You can test a filter with tasklist before using it with taskkill. This lets you confirm which processes it’ll terminate without actually terminating them.

tasklist /s remotecomputer /fi "IMAGENAME eq notepad.exe"

If the filter name is invalid, the command returns a non-zero exit code and no rows. If valid, it lists the processes that match. Note the process ID of the required process and pass it to taskkill instead of the image name, particularly if two processes share the same executable name and you want to end one of them.

A successful remote tasklist is useful evidence that the target is reachable and that remote process enumeration works. If tasklist works but taskkill doesn’t, permissions are one of the first things to check.

Remote-Specific Behavior and Limitations

These rules apply when /s is present.

• Remote process terminations are always forceful.
  Whether or not you pass /f, ending a process on a remote system is carried out forcefully. There’s no graceful remote shutdown option in taskkill. Anyone with unsaved work in that application loses it. If the target process needs to save state first, close it locally or with a different tool.
• The STATUS and WINDOWTITLE filters work locally, but not remotely.
  With taskkill, if you try to use WINDOWTITLE or STATUS with /s, you get an error. For example, if you run:

  taskkill /s FILESRV01 /fi "WINDOWTITLE eq Calculator" /im *

  The output is something like:

  ERROR: WINDOWTITLE filter is not supported on remote system.

• The wildcard (*) for /im is only accepted when a filter is applied.
  The following command fails outright with an invalid syntax error.

  taskkill /s FILESRV01 /im *

  Use it with a filter and it is accepted:

  taskkill /s FILESRV01 /fi "IMAGENAME eq note*" /im *

  With /im *, taskkill considers all image names, while the filter determines which processes are to be terminated.

Remote taskkill Examples

Here are some examples of using taskkill to end processes on remote systems, where FILESRV01 represents the remote computer.

Kill an application by name on a remote server:

taskkill /s FILESRV01 /f /im notepad.exe

Kill a process by PID, when you know exactly which process you want:

taskkill /s FILESRV01 /pid 1230

Kill with explicit credentials, useful when your logged-on account doesn’t have rights on the target. The command also uses a filter and a wildcard image name:

taskkill /s FILESRV01 /u Maindom\AdminUser /p P@ssW23 /fi "IMAGENAME eq note*" /im *

Kill a process and all its child processes:

taskkill /s FILESRV01 /pid 2134 /t

End the process with PID 2134 and any child processes that it started, but only if those processes were started by the Administrator account:

taskkill /s FILESRV01 /pid 2134 /t /fi "username eq administrator"

Caution: Avoid putting a plaintext password in /p inside a saved script. If you omit /p, taskkill prompts you for the password, which keeps the credential out of your script.

Expected Outcome

When a taskkill command completes successfully, a confirmation is printed, naming the process and PID, such as:

SUCCESS: The process "notepad.exe" with PID 17216 has been terminated.

If taskkill cannot terminate the process, it displays an error message and returns a non-zero exit code. Something like:

ERROR: The process "notepad.exe" with PID 17216 could not be terminated.
Reason: Access is denied.

If your filter matches nothing, taskkill doesn’t fail silently. It prints INFO: No tasks running with the specified criteria. When you see that, run tasklist with the same filter to check that the process is actually running and that your filter is spelled correctly.

Method 2: Kill a Remote Process with PowerShell

PowerShell is the more efficient method to terminate processes on more than one machine, or when you want to build something repeatable. For many admins, it’s also the go-to replacement for PsExec.

PowerShell Remoting Prerequisites

The following must be in place before you can use PowerShell to terminate processes on a remote machine.

Enable-PSRemoting -Force

Test-WSMan -ComputerName FILESRV01

Stop-Process via Invoke-Command

Use Invoke-Command when the same operation needs to become a script, target several machines, or include additional checks before the kill. Run:

Invoke-Command -ComputerName FILESRV01 -ScriptBlock { Stop-Process -Id 1234 -Force }

Replace FILESRV01 with the name or IP address of your target computer, and 1234 with the PID of the process you want to terminate. The ScriptBlock parameter specifies the command to be run on the remote computer.

To hit many machines at once, pass an array:

Invoke-Command -ComputerName 'FILESRV01','FILESRV02','FILESRV03' -ScriptBlock {
 Stop-Process -Name notepad -Force -ErrorAction SilentlyContinue
}

Use the -Credential parameter when you need to authenticate to the remote computer with an account other than your current logged-in account, such as when you need administrator credentials or when the target computer is in a different domain or a workgroup. For workgroup or other non-domain connections, additional WinRM configuration, such as TrustedHosts, may also be required.

Invoke-Command -ComputerName FILESRV01 -Credential maindom\User01 -ScriptBlock {
 Stop-Process -Name notepad -Force -ErrorAction SilentlyContinue
}

Perform a Dry Run

Run Get-Process first to confirm the result before actually terminating any process:

Invoke-Command -ComputerName FILESRV01 -ScriptBlock { Get-Process -Id 1234 }

Only if the output looks right, proceed to terminate the process.

Stop-Process also supports -WhatIf, which prints exactly what it would terminate and touches nothing:

Invoke-Command -ComputerName FILESRV01 -ScriptBlock {
 Get-Process -Name notepad | Stop-Process -WhatIf
}

The Variable Scope Trap

When a variable is created in a local session, it is not automatically available inside the remote script block. If you reference this local variable directly, such as $target, it refers to the $target variable in the remote session instead. If that variable hasn’t been defined there, the command won’t behave as intended. For example:

$target = 'notepad'
Invoke-Command -ComputerName FILESRV01 -ScriptBlock { Stop-Process -Name $target -Force }

The solution: use the $using: scope modifier to pass the local variable’s value to the remote script block:

$target = 'notepad'
Invoke-Command -ComputerName FILESRV01 -ScriptBlock { Stop-Process -Name $using:target -Force }

Why Doesn’t Get-Process -ComputerName Work with Stop-Process Remotely?

You will find advice online to use this one-liner for stopping a process on a remote computer. And it is presented as an alternative (in PowerShell syntax) that does not require PSremoting:

Get-Process -Name notepad -ComputerName FILESRV01 | Stop-Process

It’s true that this command is useful when PSRemoting is not available because it can query a remote computer without creating a PowerShell remoting session. But it cannot terminate a process on a remote computer. In Windows PowerShell 5.1, Get-Process supports -ComputerName and can fetch process objects from a remote computer. But Stop-Process has no -ComputerName parameter, and the underlying .NET Process.Kill() method cannot terminate a process obtained from a remote machine. The operation fails with a NotSupportedException, reported as “Feature is not supported for remote machines.”

This myth survives because the command appears to work when you test it against your own machine by name. When you specify the local computer’s hostname, .NET treats the process as local, so the process can be terminated successfully. Point the same command at a remote computer, and it fails.

There are two more limitations.

• In Windows PowerShell 5.1, Get-Process -ComputerName uses legacy RPC instead of WinRM.
• The -ComputerName parameter was removed in PowerShell 6, so it isn’t available in PowerShell 7 either.

Method 3: Kill a Remote Process with PsExec or PsKill

Neither PsExec nor PsKill comes with Windows. You need to download and deploy them first. This is a drawback considering that taskkill is already available on every Windows machine.

Still, they’re worth knowing about. Many existing scripts depend on Sysinternals tools. At the same time, organizations are restricting or blocking them because attackers abuse them for lateral movement. If your endpoint protection has blocked them, the PowerShell method given above is a practical alternative.

PsExec

If PsExec is installed and approved in your environment, you can run taskkill remotely without using the /s flag. Here are two usage examples:

psexec \\FILESRV01 taskkill /f /pid 1234

and

psexec \\FILESRV01 taskkill /f /im notepad.exe

Note the backslashes. PsExec needs them, as in \\remotecomputer and \\FILESRV01. taskkill /s doesn’t.

PsExec relies on remote service and file-sharing mechanisms, so it can fail in environments where those paths are blocked.

Important: When you run PsExec against a machine for the first time, it displays a license agreement dialog and waits for you to accept it. In an interactive session, you click through it. In a scheduled task or a deployment script, it hangs indefinitely with no output. To avoid this, include -accepteula:

psexec -accepteula \\FILESRV01 taskkill /f /im notepad.exe

PsKill

PsKill does one thing: it kills a process locally or remotely. It accepts either a PID or an image name.

pskill \\remotecomputer <PID or name>

For example:

pskill \\FILESRV01 notepad.exe

PsKill is simpler than PsExec for this one job. Still, it is a binary you have to deploy to gain a capability that taskkill gives you for free.

Which Method Should You Use to Kill a Process on a Remote Windows Computer?

The following table provides a quick comparison of the three methods:

Best Fit for Each Remote Process Termination Method

Here are some scenarios paired with the relevant method:

• A one-off kill on a single remote machine. Use taskkill /s. You don’t need to install anything, and it works on any Windows machine that allows remote WMI traffic and gives your account admin rights.
• Scripted termination across many machines. Use Invoke-Command. It runs on multiple machines in parallel, returns structured objects you can test, and handles credentials without putting a password on the command line.
• A machine with no WinRM-based PowerShell remoting configured. Use taskkill /s when you need to terminate a process remotely without relying on Invoke-Command over WinRM. PowerShell can still be used for remote administration through other technologies, such as WMI or SSH.
• A script depends on the Sysinternals suite or the target is old enough that PowerShell remoting isn’t practical. Use PsExec or PsKill when they fit the environment and your organization’s security policy. Both are legitimate Microsoft Sysinternals administration tools, although security products may flag them.

How Do You Troubleshoot Remote Process Termination Errors?

Here are some of the most common errors and what to check for each one.

“ERROR: The RPC server is unavailable.”

This error usually means that the command cannot establish the required management connection to the target computer. It affects taskkill and Get-Process -ComputerName, since both depend on RPC.

Check that the remote computer is online, DNS resolves the expected IP, and the Windows Firewall allows remote management traffic.

To test basic connectivity to the RPC Endpoint Mapper, run:

Test-NetConnection SERVER01 -Port 135

A successful test shows that TCP port 135 is reachable, but it doesn’t confirm that dynamic RPC connections (ports 49152 through 65535) or user permissions are fully open. A failed test, however, points to a network or firewall issue.

“ERROR: Access is denied.”

This error means that the command reached the target computer, but the account being used does not have the required permissions to terminate the process.

• Domain environmentsConfirm that you are using a domain account with administrative rights on the remote computer. Processes owned by another user, service accounts, or protected system components may have additional restrictions.

  taskkill /s SERVER01 /u maindom\AdminUser /pid 1234

  If the target process runs under SYSTEM, a service account, or another protected context, administrative rights alone may not be sufficient to terminate it.

• Workgroup / non-domain environmentsIf you are connecting to a workgroup computer (one that is not domain-joined) with a local administrator account, User Account Control (UAC) remote restrictions can prevent the account from receiving a full administrative token over the network.

If remote management with a local administrator account requires a full administrative token, you can disable Remote UAC token filtering on the target computer by setting LocalAccountTokenFilterPolicy to 1:

Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"
-Name "LocalAccountTokenFilterPolicy" -Value 1

This setting removes the Remote UAC restriction for affected local administrator accounts and allows Windows to provide an elevated token for remote administration. Disabling this protection can increase security risk, so use it only when required and in accordance with your organization’s security policy.

“WinRM cannot complete the operation.”

This is specific to Invoke-Command, as it depends on WinRM. First, test basic WSMan service availability from your workstation:

Test-WSMan SERVER01

If it fails, check three things:

• WinRM is enabled on the target.
• The WinRM firewall rule is open for TCP 5985 (HTTP) or TCP 5986 (HTTPS).
• If the target isn’t domain-joined, use HTTPS transport or add the target to your management machine’s TrustedHosts list when Kerberos isn’t available. On your management machine, add the target host:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "SERVER01"

A workgroup machine talking to another workgroup machine almost needs that last step because WinRM doesn’t trust an unauthenticated host by default outside a domain.

How Can Action1 Simplify Remote Process Termination at Scale?

Action1 lets IT teams run PowerShell and CMD scripts, including native Windows commands such as taskkill and Stop-Process, across selected Windows endpoints or endpoint groups from a cloud console. Instead of connecting to machines one by one, administrators can turn individual process-termination commands into a centrally managed, repeatable workflow.

To get started, an administrator can paste an ad hoc script into Action1, upload a script file, or select an existing script from the Script Library. Scripts that need to be reused can also be saved to the library, making it easier to standardize process-termination tasks across IT operations.

Once the script is ready, the administrator selects the target endpoints or endpoint groups and chooses when to run it. Action1 supports immediate execution, scheduled runs, and recurring automation, so teams can terminate processes on demand or incorporate the task into endpoint-management routines.

Offline endpoints don’t have to be missed. Administrators can configure a completion deadline that allows Action1 to retry the script when an endpoint reconnects within the specified window. This is particularly useful for remote devices that may be offline when an automation starts.

Action1 also provides controls for managing and verifying script execution. Administrators can use exit codes to determine whether a script succeeded or failed and configure automation conditions to control execution. These capabilities make process termination more manageable, especially when the same task must be repeated on many endpoints.

For larger environments, administrators can use dynamic endpoint groups to target machines based on defined criteria, while real-time endpoint visibility helps them identify and manage the devices in scope. PowerShell-based custom reporting expands options for reviewing endpoint data and automation outcomes. Role-based access control (RBAC) helps limit administrative permissions, and audit trails support accountability by recording management activities.

When a script isn’t enough and an administrator needs to investigate a machine directly, Action1 also provides browser-based remote access for manual troubleshooting. Its cloud-native architecture uses outbound-only connectivity over TCP port 443 by default, eliminating the need for a VPN or inbound management ports for routine endpoint management.

Remote process termination is just one use case for Action1. The platform supports Windows, macOS, and Linux endpoint management, OS and third-party patching, vulnerability identification and remediation, software deployment and removal, inventory, and real-time reporting. This makes Action1 a centralized management and automation tool for targeting endpoints, scheduling and repeating tasks, and verifying results.