Fix ERROR_CLUSTER_NODE_SHUTTING_DOWN 0X000013D1

You patched a node, it's been "shutting down" for 40 minutes, and now every cluster cmdlet you run spits out ERROR_CLUSTER_NODE_SHUTTING_DOWN (0X000013D1). Annoying, but fixable in about 15 minutes if you know where the cluster state is hiding.

The fix

First, confirm what the cluster actually thinks is going on. Open an elevated PowerShell on a node that's still healthy and run:

Get-ClusterNode | Format-Table Name, State, NodeWeight, DynamicWeight -AutoSize
Get-ClusterGroup | Format-Table Name, OwnerNode, State -AutoSize

You're looking for the offending node showing Down, Paused, or a state that flips between Joining and Down. If it shows Up in the console but the API still throws 0X000013D1, the cluster DB is out of sync with reality. That happens more than people admit.

Now stop the Cluster Service on the stuck node. If you can RDP in:

Stop-Service ClusSvc -Force
Get-Service ClusSvc

If RDP is dead, use the good node and hit it remotely:

Invoke-Command -ComputerName STUCK-NODE01 -ScriptBlock {
    Stop-Service ClusSvc -Force
}

With the service stopped, evict the node from the cluster database. Do this from a healthy node:

Remove-ClusterNode -Name STUCK-NODE01 -Force

Yes, evict it. Don't get sentimental. The node's config is being rebuilt from scratch on rejoin anyway, and leaving a half-shutdown entry in the DB is what keeps the error alive.

Now clean the node itself before rejoining. On STUCK-NODE01:

Remove-Item C:\Windows\Cluster -Recurse -Force -ErrorAction SilentlyContinue
Restart-Computer -Force

Once it's back up, verify the Cluster Service is set to Automatic and see if it starts clean. It won't — it's not clustered yet — but the service should be Stopped with startup type Automatic, not Disabled.

Finally, rejoin:

Add-ClusterNode -Name STUCK-NODE01 -Cluster CLUSTER01

Watch Event Viewer on both sides. You want to see Event ID 1135 (node joined) on the healthy node and no 1069 (node removed from active membership) after the fact.

Why that worked

The ShuttingDown node state isn't a normal state the cluster transitions through when you reboot a node cleanly. When you do a proper Stop-ClusterNode or graceful shutdown, the cluster marks the node as Down and that's that. ShuttingDown gets set when the Cluster Service was told to go down but the membership handshake never completed — usually because the node hung during drain, lost its witness connection mid-transition, or got yanked by a hypervisor pause.

Once that state is stamped into the cluster DB, every subsequent call that touches the node returns 0X000013D1 to prevent split-brain scenarios. The cluster is essentially saying "I'm not accepting work for this node because I don't know if it's alive." Evicting it clears the state flag from the DB and forces a fresh join, which resets everything to a known-good baseline.

Quick sanity check: if Get-ClusterNode shows the node as Up and only some cmdlets throw 0X000013D1, you might be hitting a stale WMI cache. Run Restart-Service Winmgmt -Force on the node you're querying from before you nuke anything.

Less common variations

The node is in quarantine

In Server 2016 and later, nodes can enter quarantine automatically after a set number of consecutive failures (default is 3 in a 1-hour window). A quarantined node reports as Down but the underlying state machine is still chewing on the shutdown flag. Check it:

(Get-ClusterNode -Name STUCK-NODE01).NodeQuarantineInfo

If it's quarantined, clear it:

Clear-ClusterNode -Name STUCK-NODE01 -Force

Then rejoin as usual. Don't just clear without fixing the root cause — you'll be back here in an hour.

Live Migration left the node in a bad state

If the node was mid-Live-Migration when the hypervisor was paused or the host got hit by a PSOD, the cluster thinks the node is still draining VMs. Kill any orphaned vmms.exe handles by restarting the VM management service on the node, then evict.

The witness is lying

Cloud witness or file share witness going flaky will cause nodes to flip into shutdown states that never resolve. If you're seeing 0X000013D1 on multiple nodes at once, check your witness before you touch any node:

Get-ClusterQuorum
Test-ClusterResourceHealth -Cluster CLUSTER01

Fix the witness first, then evict the affected nodes. Otherwise you'll evict one, rejoin it, and watch the next one die the same way.

Cluster service account password expired

Rare but real. If the cluster's CNO or the Cluster Service account password rolled over and wasn't updated, the node can't authenticate on rejoin and gets parked in an indefinite ShuttingDown loop. Check Event ID 1207 and 1257 in the System log on the good node.

Prevention

The single biggest cause of this is people running Stop-Service ClusSvc instead of Stop-ClusterNode. Don't do that. Stop-ClusterNode tells the cluster "I'm leaving cleanly," marks the node Down, and moves its roles. Stop-Service just yanks the rug out and leaves the shutdown flag half-written in the DB.

Other things that help:

• Set nodes to Pause before patching, not shutdown. Suspend-ClusterNode -Drain first. It takes 30 seconds and saves you an hour.
• Keep your witness highly available. Cloud witness in an Azure region separate from your primary is the safest bet for stretched clusters.
• Watch Event ID 1135 (join) and 1069 (membership loss) like a hawk. More than 2 in an hour on the same node means you have a network or timeout issue hiding underneath.
• Don't disable the Cluster Service on nodes you plan to bring back. Startup type should be Automatic (Delayed Start) in Server 2019+.
• If you're on VMware, disable any memory ballooning or suspend-to-disk on clustered VMs. A paused VM looks exactly like a hung node to the cluster.

Get the shutdown sequence right and this error basically disappears.