What does Windows error code 5009 (ERROR_CANT_EVICT_ACTIVE_NODE) mean?

ERROR_CANT_EVICT_ACTIVE_NODE

A cluster node cannot be evicted from the cluster unless the node is down or it is the last node.

ERROR_CANT_EVICT_ACTIVE_NODE is Win32 error 5009 (0x1391) and belongs to Failover clustering node eviction safety. For ERROR_CANT_EVICT_ACTIVE_NODE, the system description identifies the immediate condition but does not identify the caller, object, policy, device, service instance, or transition that produced it.

Interpret ERROR_CANT_EVICT_ACTIVE_NODE at the API boundary that returned it. Capture ERROR_CANT_EVICT_ACTIVE_NODE before logging, cleanup, or another Windows call can replace the thread-local last-error value. For ERROR_CANT_EVICT_ACTIVE_NODE, compare the recorded inputs with the documented precondition for Failover clustering node eviction safety rather than starting with a broad system repair.

Where this result appears

• ERROR_CANT_EVICT_ACTIVE_NODE can surface during Failover Cluster management during node eviction safety.
• ERROR_CANT_EVICT_ACTIVE_NODE can surface during Cluster service processing where the requested node is still active and cannot be evicted unless it is down or is the final node.
• ERROR_CANT_EVICT_ACTIVE_NODE can surface during a role or node transition whose evidence includes target node state.
• ERROR_CANT_EVICT_ACTIVE_NODE can surface during automation expected to drain workloads, pause or stop the node according to the maintenance plan, verify quorum, and then use supported eviction.

Likely causes

• For ERROR_CANT_EVICT_ACTIVE_NODE, the requested node is still active and cannot be evicted unless it is down or is the final node.
• For ERROR_CANT_EVICT_ACTIVE_NODE, the management view for node eviction safety changed before the request committed.
• For ERROR_CANT_EVICT_ACTIVE_NODE, a concurrent cluster transition invalidated cluster membership and quorum votes.
• For ERROR_CANT_EVICT_ACTIVE_NODE, the caller attempted recovery without first confirming that it could drain workloads, pause or stop the node according to the maintenance plan, verify quorum, and then use supported eviction.

Diagnostic sequence

Diagnosis of ERROR_CANT_EVICT_ACTIVE_NODE starts with the exact request type: read, write, create, transition, validation, cancellation, or administrative action. For ERROR_CANT_EVICT_ACTIVE_NODE, identify the object generation and subsystem owner, then decide whether the failure happened before side effects, during a partial transition, or after completion. For ERROR_CANT_EVICT_ACTIVE_NODE, this ordering matters in Failover clustering node eviction safety because a blind retry can hide stale state or repeat a non-idempotent change.

• For ERROR_CANT_EVICT_ACTIVE_NODE, record target node state.
• For ERROR_CANT_EVICT_ACTIVE_NODE, record cluster membership and quorum votes.
• For ERROR_CANT_EVICT_ACTIVE_NODE, record roles currently owned by the node.
• For ERROR_CANT_EVICT_ACTIVE_NODE, record drain, pause, and communication events.
• For ERROR_CANT_EVICT_ACTIVE_NODE, record UTC timestamp, cluster functional level, and the node eviction safety transition generation.

Correlate ERROR_CANT_EVICT_ACTIVE_NODE with the owning component’s operational log, the Windows System log, and any subsystem trace. Telemetry for ERROR_CANT_EVICT_ACTIVE_NODE should preserve native identifiers such as a path or file ID, handle generation, node or peer identity, policy ID, object version, offset and length, or transaction token. Retain decimal 5009, hexadecimal 0x1391, and the producing API even when a localized message is also shown.

State boundary to prove

The decisive boundary for ERROR_CANT_EVICT_ACTIVE_NODE is whether the requested node is still active and cannot be evicted unless it is down or is the final node. Prove or disprove that proposition using target node state together with cluster membership and quorum votes. When observations for ERROR_CANT_EVICT_ACTIVE_NODE disagree, preserve both and inspect the transition between them instead of choosing the more convenient value.

A focused validation for ERROR_CANT_EVICT_ACTIVE_NODE should recreate the relevant part of this situation: an administrator tries to evict a healthy node hosting roles. Draining and stopping it first satisfies the eviction boundary. The negative case should keep the responsible condition unchanged and confirm error 5009; the recovery case should change only that condition and verify a successful result without an unrecorded side effect.

Suggested diagnostic fields

For error 5009, keep winerr_5009_api, winerr_5009_object, winerr_5009_state_before, winerr_5009_request, winerr_5009_first_status, winerr_5009_verification. These fields distinguish the initial state, requested transition, first status, and verified recovery result.

Handling, retry, and recovery

Drain workloads, pause or stop the node according to the maintenance plan, verify quorum, and then use supported eviction. For ERROR_CANT_EVICT_ACTIVE_NODE, generate a focused cluster log for the failure window and preserve the first error rather than only the final management message.

Retry ERROR_CANT_EVICT_ACTIVE_NODE only after evidence shows a change in Failover clustering node eviction safety. For ERROR_CANT_EVICT_ACTIVE_NODE, initialization, asynchronous completion, recall, or service readiness can justify bounded backoff; malformed metadata, invalid identifiers, policy rejection, unsupported versions, and integrity failures require correction. Before repeating a write or configuration operation after ERROR_CANT_EVICT_ACTIVE_NODE, query completion state explicitly.

What to log for support and telemetry

• For ERROR_CANT_EVICT_ACTIVE_NODE, log decimal 5009, hexadecimal 0x1391, and the producing API.
• For ERROR_CANT_EVICT_ACTIVE_NODE, log the target object and observed Failover clustering node eviction safety state.
• For ERROR_CANT_EVICT_ACTIVE_NODE, log caller identity, process and thread IDs, machine or node identity, and UTC time.
• For ERROR_CANT_EVICT_ACTIVE_NODE, log attempt number, elapsed time, previous result, and any partial side effect.
• For ERROR_CANT_EVICT_ACTIVE_NODE, retain the first lower-level or component-specific error before Win32 translation.

Difference from nearby codes

For ERROR_CANT_EVICT_ACTIVE_NODE, eRROR_CANT_EVICT_ACTIVE_NODE names the cluster-specific boundary for node eviction safety; a generic Win32 paraphrase would lose the object and transition context.

Practical example

An administrator tries to evict a healthy node hosting roles. Draining and stopping it first satisfies the eviction boundary.

Developer and administrator guidance

Code that handles ERROR_CANT_EVICT_ACTIVE_NODE should keep its Win32 domain visible across exceptions, RPC responses, and JSON or REST wrappers. For ERROR_CANT_EVICT_ACTIVE_NODE, administrators should verify the subsystem evidence before changing policy, deleting state, forcing failover, or replacing storage. Recovery is demonstrated only when a test observes 5009, changes the responsible condition, and confirms that the same operation succeeds without hidden data loss.

References

• Microsoft: System Error Codes (4000–5999) — reference for error 5009.
• Microsoft: Failover clustering documentation — reference for error 5009.
• Microsoft: Get-ClusterLog — reference for error 5009.
• Microsoft: Troubleshoot unexpected cluster failover — reference for error 5009.

Looking for a different code? Search another status or error code.