Fix Cluster Node Not Found 0XC0130005 on Windows Server

Cause 1: Corrupt Cluster Registry Key

What's actually happening here is that the cluster service reads node-specific info from the registry before it even talks to other nodes. If that key is missing or has bad data, you get 0XC0130005. I see this a lot after server reboots that didn't cleanly shut down the cluster service, or after someone manually edited the registry (don't).

The fix is to restore the node's identity from backup or rebuild it. Here's what I do:

1. Open an elevated PowerShell prompt as Administrator.
2. Run Get-ClusterNode -ErrorAction Stop. If it throws 0XC0130005, you're in the right place.
3. Stop the cluster service on the broken node: Stop-Service ClusSvc
4. Back up the problematic registry key: reg export HKLM\Cluster\Nodes\NodeID C:\Backup\cluster_node.reg (replace NodeID with the actual GUID shown in the key).
5. Delete the entire HKLM\Cluster\Nodes\NodeID key. Yes, delete it — the cluster service will recreate it when it joins the cluster again.
6. Start the cluster service: Start-Service ClusSvc
7. Force the node to rejoin: Add-ClusterNode -Name $env:COMPUTERNAME -Force

The reason step 5 works is that the cluster service, when it starts and finds no local node key, assumes it's a fresh install. It then asks the cluster for its own identity, which forces a re-creation of that registry key. Without the force flag in step 7, it'll try to read the missing key and fail again.

Cause 2: Node Object Deleted from Active Directory

If you're running a domain-joined cluster (which is most of them), the cluster node object in Active Directory can get deleted—maybe by a cleanup script, maybe by an overzealous admin. The cluster service checks AD for its computer object, and if it's gone, you get 0XC0130005.

To check this: open AD Users and Computers, look under the CN=Computers container or the OU where your cluster nodes live. Find the node's computer account. If it's missing, here's the fix:

1. On a working cluster node (or domain controller), open an elevated PowerShell.
2. Run Get-ADComputer -Identity $nodeName -Properties *. If it returns nothing, the object is gone.
3. On the broken node, run Reset-ComputerMachinePassword -Server $domainController to re-authenticate.
4. Then rejoin the cluster as shown in Cause 1, step 7: Add-ClusterNode -Name $env:COMPUTERNAME -Force

What happens is that resetting the machine password re-creates the AD computer object with a fresh password hash. The cluster service then sees a valid object and proceeds past the 0XC0130005 check.

Cause 3: Node Quarantined by Cluster Quorum

Less common, but I've seen it: the cluster's quorum logic decides this node is unreliable and quarantines it. The node's local info is still there (registry key is fine), but the cluster marks it as not-found to prevent split-brain scenarios.

Check this in the cluster log. On a working node, run:

Get-ClusterLog -Node $brokenNode -Destination C:\ClusterLogs

Look for lines like Quarantine or NodeNotReachable. If you find them, the fix is to clear the quarantine flag:

1. On a working node, run: Clear-ClusterNode -Name $brokenNode -Force
2. Then restart the cluster service on the broken node: Restart-Service ClusSvc
3. Verify node is up: Get-ClusterNode -Name $brokenNode should show State: Up

The reason this happens is often network flapping—if the node keeps losing connection to the cluster, the cluster can quarantine it after a few minutes. So after clearing it, check your network team's logs for packet loss or switch issues.

Quick-Reference Summary Table