> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows/windows-process-kill.md).

# Windows process kill

Windows process kill is a Windows chaos fault that terminates processes on the target Windows VM. You can specify them by PID (`PROCESS_IDS`), by name (`PROCESS_NAMES`), or by both. Set `FORCE=enable` to terminate forcefully (`/F` equivalent); otherwise the fault attempts a normal close. The fault runs through the Windows chaos agent installed as a service on the target VM and runs for `DURATION`.

Use this fault to test how a workload running on a Windows VM behaves when a critical process is killed: whether a service recovery action restarts it inside the SLA, whether replicas absorb the load, whether monitoring detects the regression within the alerting SLA, and whether on-call alerts fire correctly.

{% hint style="info" %}
**RUN YOUR FIRST EXPERIMENT**

If you have not configured the chaos infrastructure yet, go to [Quickstart](/resilience-testing/chaos-engineering/new-to-chaos-engineering/quickstart.md) to install the chaos infrastructure and run an experiment end to end.
{% endhint %}

***

### Use cases <a href="#use-cases" id="use-cases"></a>

* **Crash resilience:** When a critical process dies, does the service recovery action restart it inside the SLA?
* **Cluster failover:** Does Windows Failover Cluster move workloads off the affected VM when a critical process disappears?
* **Alert fidelity:** Do downstream alerts fire inside the alerting SLA?

***

### Prerequisites <a href="#prerequisites" id="prerequisites"></a>

* **Windows chaos infrastructure:** Install the chaos agent on the target VM. Go to [Windows requirements and security considerations](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows/windows-chaos-permissions.md).
* **Process identifier:** You know the PID or process name to kill.
* **Permissions to kill the process:** The agent's user can terminate the process. System processes require administrator privileges.

***

### Supported environments <a href="#supported-environments" id="supported-environments"></a>

| Platform                                                  | Support status                                                                                                                                                                                                                                                              |
| --------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Windows Server VMs with the Windows chaos agent installed | Supported                                                                                                                                                                                                                                                                   |
| Linux VMs                                                 | Not supported (use [VMware process kill](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/vmware/linux/vmware-process-kill.md) or [Linux process kill](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-process-kill.md)) |

***

### Permissions required <a href="#permissions-required" id="permissions-required"></a>

This fault is classified as **Basic**. Killing user-owned processes does not require administrator; killing system or admin-owned processes requires the agent to run as administrator.

***

### Fault tunables <a href="#fault-tunables" id="fault-tunables"></a>

**One of these is required**

| Tunable         | Description                                                                 | Default |
| --------------- | --------------------------------------------------------------------------- | ------- |
| `PROCESS_IDS`   | Comma-separated list of PIDs to terminate.                                  | `""`    |
| `PROCESS_NAMES` | Comma-separated list of process names to terminate (without `.exe` suffix). | `""`    |

**Chaos parameters**

| Tunable     | Description                                                              | Default   |
| ----------- | ------------------------------------------------------------------------ | --------- |
| `DURATION`  | Total duration of the fault as a Go duration string (for example `30s`). | `30s`     |
| `FORCE`     | `enable` to force-kill (`/F`); `disable` for a normal close.             | `disable` |
| `RAMP_TIME` | Wait period in seconds before and after the fault.                       | `0`       |

Tunables that apply to every fault are documented in [common tunables for all faults](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/common-tunables-for-all-faults.md).

***

### Fault execution in brief <a href="#fault-execution-in-brief" id="fault-execution-in-brief"></a>

The Windows chaos agent on the target VM terminates each PID in `PROCESS_IDS` and each process matching `PROCESS_NAMES` for `DURATION`. With `FORCE=enable` the agent uses a forceful terminate; otherwise it requests a normal close.

***

### Expected behavior during fault execution <a href="#expected-behavior-during-fault-execution" id="expected-behavior-during-fault-execution"></a>

* Each targeted process is terminated.
* Service Control Manager may restart configured services per their recovery action.
* Replicas (if any) absorb traffic during the gap.
* After the duration ends, the fault exits without further action; supervised processes are expected to be running normally.

{% hint style="info" %}
**WHEN THE FAULT ENDS**

The fault does not restart processes. Recovery depends on Windows Service Recovery actions or user intervention.
{% endhint %}

#### Signals to watch <a href="#signals-to-watch" id="signals-to-watch"></a>

* **Process up:** Use a [command probe](/resilience-testing/chaos-testing/probes/command-probe.md) running `Get-Process <name>` and assert success after the SLA.
* **Workload health:** Use an [HTTP probe](/resilience-testing/chaos-engineering/use-chaos-engineering/probes/http-probe.md) on a user-visible endpoint.

***

### Verify the fault execution effect <a href="#verify-the-fault-execution-effect" id="verify-the-fault-execution-effect"></a>

1. **During the chaos window, on the VM, run `Get-Process <name>` in PowerShell.**

   The process should briefly disappear and (if a recovery action restarts it) reappear with a new PID.
2. **Inspect Event Viewer → Application logs.**

   You should see entries from Service Control Manager when a service is restarted.

***

### Recovery and cleanup <a href="#recovery-and-cleanup" id="recovery-and-cleanup"></a>

* **Supervised services:** Windows Service Recovery actions restart them automatically.
* **Unsupervised processes:** Restart them manually or via your management tooling.
* **Abort:** Stopping the experiment also stops further iterations of the fault.

***

### Limitations <a href="#limitations" id="limitations"></a>

* **PID changes between iterations:** When a process is restarted, its PID changes. If you target by PID and iterate, you must look up the new PID. Targeting by `PROCESS_NAMES` avoids this.
* **No auto-restart:** The fault does not restart killed processes; supervision is the user's responsibility.

***

### Troubleshooting <a href="#troubleshooting" id="troubleshooting"></a>

<details>

<summary>Windows process kill fails with access denied in Harness Chaos Engineering</summary>

The chaos agent's user account may not be able to kill the targeted process. For system or admin-owned processes, reinstall the chaos agent as administrator.

</details>

<details>

<summary>Killed process did not restart</summary>

The fault only kills the process; restart is up to Windows Service Recovery or your own supervisor. Inspect Services.msc, open the service's properties, switch to the Recovery tab, and configure Restart on first/second/subsequent failures.

</details>

***

### Related faults <a href="#related-faults" id="related-faults"></a>

* [Windows CPU stress](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows/windows-cpu-stress.md): Stress CPU instead of killing processes.
* [Windows memory stress](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/windows/windows-memory-stress.md): Stress memory instead of killing processes.