Fix cluster local node not found error 0x000013B3

What triggers this error

You'll see ERROR_CLUSTER_LOCAL_NODE_NOT_FOUND (0x000013B3) when the Cluster service on a node can't start because the node's own identity is missing from the cluster database. This typically pops up after a forced reboot during a quorum vote, a sudden power loss, or a manual edit of the cluster registry that went sideways. I've seen it most often on Windows Server 2019 and 2022 hyper-converged clusters, where a node that got evicted from the cluster tries to rejoin and finds its own record gone.

The error message itself is blunt: "The cluster local node information was not found." It's not a network issue or a permission problem — the service literally can't find itself in the list of nodes stored in the cluster database.

Why this happens

The cluster database lives in the cluster hive under HKLM\Cluster\Nodes. Each node has a subkey named after its node ID (like 1, 2, 3). Inside each subkey, the NodeName value holds the machine name. The cluster service reads HKLM\Cluster\Nodes and tries to match the local machine's name to one of those entries. If it can't find a match — or if the entire Nodes key is missing or empty — you get error 0x000013B3.

What's actually happening here is one of three things:

The node's registry entry got corrupted or deleted. Happens when antivirus or a backup tool messes with the cluster hive.
The node was cleanly removed from the cluster but the local cluster hive still exists. The service starts, sees no node list, and panics.
The cluster database itself is stale or inconsistent. The node ID in the local hive doesn't match what the rest of the cluster sees.

The fix depends on whether this is a single-node cluster (like a stretched cluster witness) or a multi-node cluster where other nodes are still running.

The fix — step by step

Step 1: Stop the cluster service

Open PowerShell as Administrator on the affected node and run:

Stop-Service -Name ClusSvc -Force

This halts the cluster service and stops it from locking the registry hive. If you can't stop it normally, use net stop clussvc /y. Force is safe here because the node isn't part of the cluster anyway.

Step 2: Back up the cluster registry hive

Before touching anything, take a copy of the cluster hive. Run:

Copy-Item -Path "HKLM:\Cluster\Nodes" -Destination "C:\ClusterBackup\Nodes_$(Get-Date -Format yyyyMMdd_HHmmss)" -Recurse

If you don't have PSRemoting or your Windows build doesn't support Get-PSDrive on HKLM, use reg export instead:

reg export HKLM\Cluster\Nodes C:\ClusterBackup\nodes_backup.reg

You need this backup in case a step goes wrong — you can restore it later.

Step 3: Check if any other nodes are online

Run this from a node that's still part of the cluster (if there is one):

Get-ClusterNode

If the affected node's name shows up with a status of Down, you're in luck. The node still exists in the cluster database, just not in the local registry. If it doesn't show up at all, you'll need to add it back manually later.

Step 4: Find the local node ID and re-add it

On the affected node, check what's in the cluster registry:

Get-ItemProperty -Path "HKLM:\Cluster\Nodes\*" | Select-Object PSChildName, NodeName

If this returns nothing, or returns a node that doesn't match your machine's name, you need to create the entry.

First, find your machine name:

$env:COMPUTERNAME

Now, you have two options. The cleanest way is to rejoin the cluster from scratch. If you have access to another node in the cluster, run this from the working node:

Add-ClusterNode -Name <AffectedNodeName> -Force

The -Force flag bypasses the local node's existing hive and rewrites it. This is the real fix.

If there's only one node (or the cluster is completely down), you'll need to rebuild the local node entry manually. Here's how:

Delete the entire HKLM\Cluster key. Yes, delete it. The cluster service will recreate it on next start if you do it right.
Then run this from PowerShell as Admin to recreate the cluster configuration:

New-Cluster -Name <ClusterName> -Node $env:COMPUTERNAME -Force

If you're recreating a single-node cluster, you might lose quorum settings. After the cluster starts, run:

Set-ClusterQuorum -NoWitness

Or set your witness back if you had one.

Step 5: Start the cluster service

Start-Service -Name ClusSvc

Check the event log for Cluster source for any remaining errors. If you see 0x000013B3 again, the registry didn't get updated correctly — go back to step 2 and restore the backup, then try a different approach.

What to check if it still fails

File-level cluster corruption. The cluster database also lives in C:\Windows\Cluster\CLUSDB. If that file is corrupted, the registry fix won't work. Run chkdsk /f on the system drive and then check the file's integrity with esentutl /g C:\Windows\Cluster\CLUSDB.
Conflicting services. Antivirus with real-time registry protection can block cluster hive writes. Temporarily disable it for the affected node during the fix.
Quorum witness mismatch. If the node was part of a cluster with a file share witness or cloud witness, the witness might have metadata that doesn't match what you just created. Remove and re-add the witness after the node rejoins.
Permissions on the cluster hive. The NETWORK SERVICE account needs read/write access to HKLM\Cluster. If you restored from a backup that changed the ACL, reset it with sc sdset clussvc (look up the correct SDDL for your OS version).

The reason step 3 and step 4 work is because you're either fixing a missing registry entry or forcing the cluster service to rebuild its local database from the cluster's actual state. Most people forget to check if the node still exists in the cluster before nuking the local hive — don't skip that part. If you nuke a node that the cluster still expects to see, you'll have to evict it cleanly from a working node, which is an extra step you don't need.