STATUS_CLUSTER_NODE_ALREADY_UP 0x80130001 Fix That Actually Works

I've seen this error more times than I'd like to admit. A client calls, says their SQL cluster won't start. You go to bring a node online, and Failover Cluster Manager throws 0x80130001 – The cluster node is already up. But the node is clearly down. The service won't start. The whole thing is stuck.

Before you start ripping out the cluster and rebuilding it (I've had a guy do that once, don't be that guy), know this: usually the fix takes two minutes and involves nothing more than restarting the Cluster service on the node that's already up. Here's the breakdown.

Cause #1: Cluster Service Thinks the Node is Up When It Isn't

This happens when the Cluster service (ClusSvc) on the node that's already running loses its connection to the node you're trying to start. The quorum still sees the down node as up because it hasn't received a heartbeat – but the cluster state cache is stale. The most common trigger I've seen: a network hiccup during a node reboot, or someone killed the Cluster service on the down node without letting it go through a clean shutdown.

The fix: On the node that's already up (the one that's hosting the cluster), restart the Cluster service. That clears the stale state.

# On the running node, open PowerShell as admin
Restart-Service -Name ClusSvc -Force

Wait 30 seconds, then try bringing the other node online from Failover Cluster Manager. In my experience, 9 times out of 10 that's it. If you can't restart the service on the running node because it's hosting critical resources, you can also try to clear the node state using the cluster command:

# On the running node
cluster node <DownNodeName> /forcecleanup

That's a newer command, available in Windows Server 2016 and later. It forces the cluster to forget the node's state. Use it with care, but it's a lifesaver.

Cause #2: The Node's Cluster Service Won't Start Because of a Hung Process

Second most common: the node you're trying to start is stuck. The Cluster service is trying to start, but something is holding onto a file handle or a network resource. You'll see the service start and then stop, or it just never fully comes up. The error 0x80130001 appears when you try to force it online because the cluster still thinks it's up from the last boot.

The fix: Kill the hung processes, then start the service manually. Look for any RHS.exe or clussvc.exe processes that are stuck.

# On the stuck node, as admin
Stop-Service -Name ClusSvc -Force
Stop-Process -Name clusvc -Force -ErrorAction SilentlyContinue
Stop-Process -Name RHS -Force -ErrorAction SilentlyContinue
Start-Service -Name ClusSvc
# Then check the status
Get-Service -Name ClusSvc

After the service starts and stays up, the node will automatically rejoin the cluster. If it doesn't, you'll need to look at the event logs. Specifically, check the Cluster service log in Event Viewer under Applications and Services Logs > Microsoft > Windows > FailoverClustering. Look for any errors that mention a timeout or a network failure.

Cause #3: DNS or Network Configuration Mismatch (Less Common, But I've Seen It)

Sometimes the error is a red herring. The cluster node is actually up, but the cluster can't reach it because of a DNS issue. I had a client once where the node's IP changed but DNS was still pointing to the old one. Cluster tried to bring it online, got a response from the old IP, and assumed it was already up.

Fix: Check DNS records for the node name. Make sure it resolves to the correct IP. Also check the cluster network settings – the node should be on the same network as the other nodes.

# On the running node
Resolve-DnsName <DownNodeName>
# Or use nslookup
nslookup <DownNodeName>

If the DNS is wrong, fix the record and then restart the cluster service on all nodes. That's rare but it happens.

Quick-Reference Summary

That's the whole deal. I've used this on Server 2012 R2, 2016, and 2019. The brute-force restart of the Cluster service on the running node clears it almost every time. If you've tried all three and still get the error, then start digging into the FailoverClustering event log – that's where the real answer hides, but it's usually a network or storage issue by that point.