Fix ERROR_SHUTDOWN_CLUSTER 0X00001390 on Windows Server

Quick answer for pros

If you see 0X00001390, the Cluster service on that node is shutting down. Run Get-ClusterNode in PowerShell to confirm the node status, then restart the Cluster service via Restart-Service ClusSvc. If it doesn't come back, check the cluster log at C:\Windows\Cluster\Reports for a stuck quorum or a resource that won't drain.

What's this error really telling you?

I've seen this error pop up on Windows Server 2016, 2019, and 2022 when a node in a Failover Cluster decides to take itself offline. The system sends a graceful shutdown signal to the cluster stack, but something blocks it mid-process. Most of the time, it's a resource that refuses to drain—like a file share or a VM that's locked. Other times, it's a quorum vote that times out because the node can't reach the witness disk or cloud witness. Either way, you're stuck with a node that's in a limbo state: not fully down, but not serving anything.

I tripped over this myself on a Server 2016 cluster running SQL Server. The node showed "Paused" but wouldn't go back to "Up" until I killed the hung resource. Here's how to fix it without losing your hair.

Step-by-step fix

Check the node state
Open PowerShell as Administrator and run:
```
Get-ClusterNode
```
Look at the State column. If it's "Down" or "Paused", proceed. If it's "Up" but the error persists, skip to Step 4.
Restart the Cluster service
This is the first thing to try. On the affected node, run:
```
Restart-Service ClusSvc
```
Wait 30 seconds, then check Get-ClusterNode again. If the state changes to "Up", you're done. If it stays "Down" or goes back to shutting down after a minute, move on.
Check the cluster log
Navigate to C:\Windows\Cluster\Reports and open the most recent Cluster.log file. Search for "0x1390" or "shutdown". You'll see something like:
```
00001234.00001234::2025/03/15-10:15:22.123 INFO  [FM] Node is shutting down: ERROR_SHUTDOWN_CLUSTER
```
Scroll above that line—look for a resource that's stuck in "OnlinePending" or "OfflinePending". That's your culprit.
Force-quit the hung resource
If you find a resource name in the log, run:
```
Get-ClusterResource "ResourceName" | Stop-ClusterResource -Force
```
Replace ResourceName with the actual name. The -Force flag skips the graceful drain, which is what's blocking the shutdown. After that, restart the Cluster service again.
If nothing works, reboot the node
This is a brute-force fix, but it's reliable. Run:
```
Restart-Computer -Force
```
After the reboot, the node should rejoin the cluster automatically. If it doesn't, run Start-ClusterNode to force it.

Alternative fixes when the main one fails

Check the quorum configuration

If the node can't talk to the witness—a file share, a disk, or a cloud witness—it'll shut itself down. Run:

Get-ClusterQuorum

Verify the witness path is reachable. For a cloud witness, check internet connectivity. For a disk witness, make sure the disk is online in Disk Management. If the witness is down, you can temporarily disable it with:

Set-ClusterQuorum -NoWitness

But only do this to get the node back up. Re-enable the witness once the issue is resolved.

Review recent changes

This error often follows a Windows Update or a driver update. Check Get-HotFix for updates installed in the last 48 hours. Roll them back if possible with wusa /uninstall /kb:number. Network drivers are a common culprit—if you updated a NIC driver, revert it.

Use a manual cluster log dump

If the log file is huge, filter it like this:

Get-Content "C:\Windows\Cluster\Reports\Cluster.log" | Select-String "shutdown"

This cuts the noise and shows you the exact shutdown sequence.

Prevention tips

Keep your cluster nodes updated together—apply the same patches to all nodes within a day. Staggered updates can cause quorum mismatches.
Test resource drain before maintenance. Before you patch or reboot a node, manually drain it with Suspend-ClusterNode -Drain. If it hangs, you'll know before you hit the shutdown button.
Monitor cluster events in Event Viewer under Applications and Services Logs\Microsoft\Windows\FailoverClustering\Operational. Set a triggered task to email you when Event ID 1135 (node lost quorum) appears.
Use at least two witnesses—a disk witness and a file share witness, for example. This gives you redundancy if one fails.

I've been running clusters since Server 2008 R2, and 0x1390 still gets my heart rate up. But once you know the pattern—hung resource, quorum issue, or bad patch—it's a ten-minute fix. Stay calm, check the log, and you'll be back in business.