The cluster service on this node didn't just crash — it was told to stop. ERROR_CLUSTER_MEMBERSHIP_HALT (0x00001704) means the membership engine (the part of the cluster that tracks which nodes are alive and voting) decided this node no longer belongs in the cluster. The service then halts itself. You'll see it in the System event log as Event ID 1135 or 1069, and the Cluster log will have a line like Membership engine requested shutdown of the cluster service on this node.
This isn't a random failure. Something happened — a lost heartbeat, a failed quorum vote, a node eviction — and the cluster protected itself. Let's fix it. Work through these steps in order and stop when the service stays up.
Step 1: The 30-second fix — restart the Cluster Service
Yeah, I know. But sometimes the membership engine halts after a transient network blip, and the service just needs a nudge. If the cluster is healthy otherwise, this is worth 30 seconds.
Open an elevated PowerShell on the affected node and run:
Restart-Service -Name ClusSvc -Force
Get-ClusterNodeIf the node shows Up and stays that way for 5 minutes, you're probably done. If it halts again immediately, the underlying cause is still there. Move to Step 2.
Step 2: The 5-minute fix — check quorum and node status
What's actually happening here is the membership engine counts votes. If this node can't reach enough other nodes to form a quorum, it halts itself to avoid split-brain. So the first thing to check is whether the cluster even has quorum.
Run this from any node that's still up (or from the affected node if the service is running):
Get-ClusterQuorum
Get-ClusterNode | Format-Table Name, State, NodeWeight, DynamicWeight
Get-ClusterGroup | Format-Table Name, State, OwnerNodeThings to look for:
- Quorum resource is offline or missing. If you're using a disk witness or file share witness, and it's unreachable, the cluster loses its tie-breaker.
- Other nodes are Down or Paused. If half your nodes are already evicted, this node might be the last one standing and can't form quorum alone.
- NodeWeight is 0. Someone may have set this node's vote to 0 during maintenance and forgot to set it back.
If a node weight is wrong, fix it:
(Get-ClusterNode -Name "NODE01").NodeWeight = 1If the witness is the problem, reconfigure it:
Set-ClusterQuorum -NodeAndFileShareMajority \\fileserver\witnessRestart the cluster service again after fixing quorum. If it stays up, you're done. If not, the problem is deeper — probably network or a node that's actively being evicted.
Step 3: The 15+ minute fix — dig into cluster logs and network
This is where most people give up and open a Microsoft case. Don't. The cluster log tells you exactly why the membership engine voted to halt. You just have to read it.
Generate and read the cluster log
Run this on the affected node:
Get-ClusterLog -TimeSpan 15 -Destination C:\Temp\clusterlogOpen the file and search for Membership and Halt. You'll see entries like:
[NM] Node NODE02 missed 3 consecutive heartbeats
[NM] Node NODE02 evicted from cluster
[NM] Membership engine requested shutdown of the cluster service on this nodeThe reason step 3 works is this: the membership engine logs every heartbeat miss and every eviction decision. The node that halted is usually the victim — the one that got evicted by the rest of the cluster. So the real question is: why did the other nodes decide this one was dead?
Common root causes and what to do
| Symptom in log | Likely cause | Fix |
|---|---|---|
| Missed heartbeats from one node | Network latency or packet loss between cluster nodes | Check switch, NIC teaming, and whether cluster traffic is sharing a saturated link |
| Node evicted during backup window | Backup software freezing the cluster service or VSS | Exclude cluster disks from backup or adjust backup timing |
| Repeated evictions of the same node | Failing NIC, driver bug, or CPU starvation | Update NIC drivers, check for firmware issues, review CPU/memory pressure |
| Quorum lost during patching | Too many nodes rebooted at once | Patch one node at a time; use cluster-aware updating |
Verify network and firewall
Cluster nodes talk over specific ports. If a firewall rule got pushed by Group Policy, heartbeats die silently.
- UDP 3343 — cluster heartbeat (yes, it's UDP, and yes, that matters)
- TCP 3343 — cluster communication
- RPC dynamic ports — for cluster API calls
- SMB 445 — if you're using a file share witness
Test connectivity from the affected node to every other node:
Test-NetConnection -ComputerName NODE02 -Port 3343
Get-NetFirewallRule -DisplayName "*Cluster*" | Format-Table Name, Enabled, Direction, ActionIf the firewall rules are disabled or missing, re-enable the built-in cluster rules:
Enable-NetFirewallRule -DisplayGroup "Failover Clusters"One more thing: if you're running cluster nodes on different subnets, make sure the cluster network is configured correctly. Multi-subnet clusters need either OR dependencies or a proper stretch-cluster setup. Misconfigured multi-subnet clusters cause exactly this error on a regular basis.When to step back and check the obvious
Before you spend hours on cluster logs, confirm the boring stuff:
- Is the cluster service actually set to Automatic?
Get-Service ClusSvc | Select StartType - Did someone recently change cluster properties, like
SameSubnetThresholdorCrossSubnetThreshold? Lowering these makes the cluster more aggressive about evicting nodes. - Is there a pending reboot? Cluster nodes that haven't rebooted after a patch can behave erratically.
- Are the nodes time-synced? Kerberos failures from clock skew can cause cluster communication to fail.
The membership engine doesn't halt for no reason. It halts because it decided this node is a liability. Find out why it made that call, fix the underlying condition, and the error stops coming back.