Fix ERROR_CLUSTER_SHUTTING_DOWN 0x139E on Failover Cluster

Cluster service is stopping, often from a node eviction, a quorum loss, or a rogue shutdown command. Walk through the event log, check quorum, and stop other nodes from pulling the cluster down.

Quick answer

Check the cluster event log for a node that lost quorum or was evicted, verify the current quorum configuration, then force-start the cluster with Start-ClusterNode -FixQuorum on the node that holds the most up-to-date copy of the cluster database.

What's actually happening here

0x139E is the Windows error code for ERROR_CLUSTER_SHUTTING_DOWN. It means the Cluster service on that node is in the process of stopping. You'll usually see it as an event in the System log or as a message when you try to run a cluster command like Get-ClusterNode or Get-ClusterResource. The service isn't crashing randomly — it's being told to stop, either by the cluster itself or by a manual shutdown.

In my experience, this error appears in two common scenarios:

A node lost quorum and the cluster service stopped itself to avoid a split-brain situation.
An administrator or a monitoring script ran Stop-Service ClusSvc or Stop-ClusterNode on a node, and other nodes are following suit because the cluster detects an unhealthy state.

The reason the whole cluster starts shutting down is by design. If one node stops responding, the remaining nodes try to form a new quorum. If they can't, they stop the Cluster service to prevent data corruption. So the real question isn't “how do I stop the shutdown?” — it's “why did the cluster lose quorum?”

Fix steps

Read the event log first
Open Event Viewer on the affected node and go to Applications and Services Logs → Microsoft → Windows → FailoverClustering → Operational. Look for event ID 1135, which lists the nodes that didn't respond. That tells you which node dropped off and why.
Check the cluster.log
If the event log is thin, read C:\Windows\Cluster\Cluster.log on each node. Grep for “Lost quorum” or “evicted”. This file is verbose, so filter with Get-Content Cluster.log | Select-String "quorum|evict|stop".
Verify quorum configuration
Run Get-ClusterQuorum on any node that's still up. If it shows QuorumConfiguration: Node and File Share Majority and the file share witness is unreachable, that's your problem. The witness is a single point of failure.
Force the cluster to start with the right node
On the node that has the most recent copy of the cluster database (usually the one that was the primary before the failure), open PowerShell as Administrator and run:
```
Start-ClusterNode -FixQuorum
```
This tells the cluster to ignore the normal quorum rules and start with just this node. It's a last resort because it can cause data loss if the wrong node wins. Only do this if you know which node had the latest changes.
Stabilize the quorum
Once the cluster is back up, run Test-Cluster to validate the configuration. If the witness was the issue, either fix its network path or change the quorum to a dynamic quorum with Set-ClusterQuorum -NodeAndFileShareMajority "path" after you've confirmed the share is reachable.

Alternative fixes if the main one fails

If -FixQuorum doesn't bring the cluster back, you're likely dealing with a deeper problem. Try these in order:

Reboot the other nodes — Sometimes a node is stuck in a bad state and keeps sending shutdown requests. Rebooting all nodes except the one you want to force-start clears that up.
Check for a rogue shutdown script — Look at Task Scheduler and any monitoring tools (SCOM, Nagios, etc.) for a scheduled task that runs Stop-Service ClusSvc. I've seen a “maintenance” script that was meant to stop the service on one node but was accidentally deployed to all nodes.
Manually edit the cluster database — This is advanced and risky, but if you're certain the cluster registry hive is corrupted, you can use cluscfg from the Windows Server installation media to repair it. Don't do this unless you're comfortable with registry surgery.

Prevention tip

The best way to avoid 0x139E is to ensure your quorum configuration matches your node count. For an odd number of nodes, use Node Majority. For an even number, add a file share witness or a cloud witness. Also, never run Stop-Service ClusSvc on a node unless you intend to take it out of the cluster for maintenance — use Suspend-ClusterNode instead, which drains roles gracefully.

One more thing: check your DNS registration. The cluster relies on name resolution for nodes to find each other. If a node's DNS record goes stale, it can appear offline and trigger a quorum loss. Set the DNS registration to update every 5 minutes or use the cluster's built-in Register-ClusterNode cmdlet after any network change.