Fix ERROR_RESOURCE_NOT_FOUND 0x0000138F in Cluster

You're staring at 0x0000138F and wondering where your cluster resource went. I get it.

I've seen this error pop up in the weirdest moments—right when you're trying to fail over a critical VM, during a routine patch cycle, or after someone accidentally deleted a resource in Failover Cluster Manager. The message is useless: "The cluster resource could not be found." But the problem is almost always one of two things: a stale GUID reference in the cluster database, or a DNS issue where the cluster name object can't resolve.

The fix that works 9 times out of 10

Skip the cluster repair wizard. Skip rebuilding resources. Here's what I do:

Open Failover Cluster Manager and connect to the cluster.
Right-click the affected resource and select Properties. If you can't see the resource at all, skip to step 4.
Go to the Dependencies tab. Check if any dependency shows "Resource not found" or has a GUID that looks like {12345678-1234-1234-1234-123456789abc} instead of a friendly name. If you see a GUID, that's the culprit. Remove it and add the correct resource back.
Still stuck? Open PowerShell as Admin on the node that owns the resource. Run:
```
Get-ClusterResource -Name "*" | Where-Object {$_.State -eq 'Offline' -or $_.State -eq 'Failed'}
```
Look for the resource that matches your error—it'll show the exact name and GUID. Once you find it, run:
```
Get-ClusterResource -Name "YourResourceName" | Update-ClusterResource -Force
```
This forces the cluster to re-read the resource definition from disk and clear whatever stale reference it's caching.
Check DNS—because this error loves DNS failures. On a domain controller, run:
```
nslookup yourclustername.yourdomain.com
```
If it doesn't resolve to the cluster's IP address, delete the stale A record and let the cluster recreate it. Or update it manually.

After the fix, run Test-Cluster to validate the cluster. Then test failover manually.

Why this works

When a cluster resource goes missing, Windows caches its GUID in the cluster database. If that GUID gets deleted or corrupted—say, after a node reboot or a failed backup—the cluster tries to find it by name but can't match it. The error code is 0x0000138F, which translates to "I can't find the object you're looking for." The Update-ClusterResource -Force command forces the cluster to flush that cache and reload the resource from disk. For DNS, the cluster uses the Cluster Name Object (CNO) to register its resources. If DNS is broken, the cluster can't locate the resource's host record, so it throws this error.

Less common variations

Sometimes the fix is different. Here's what else I've seen:

Resource in a different group — A dependency points to a resource that was moved to another group. Open Dependencies on the failing resource and update the target resource path.
Corrupted cluster database — If the error affects multiple resources, try restoring the cluster from a backup. Run Get-ClusterResource | Restore-Cluster from a known good backup. I've had to do this twice in ten years.
IPv6 conflict — If you have IPv6 enabled on cluster nodes, disable it on the cluster network. Use Get-ClusterNetwork | Set-ClusterNetwork -EnableIPv6 $false. IPv6 can cause name resolution confusion.
Antivirus quarantine — McAfee and Sophos have been known to quarantine cluster resource DLLs. Check the AV logs on each node for files like clusres.dll or resbase.dll. Exclude the cluster directory (C:\Windows\Cluster).

Prevention

Stop this from happening again:

Keep DNS clean — Set DNS aging and scavenging for your cluster zone. Delete stale records weekly.
Monitor cluster events — Enable event forwarding to your SIEM or just watch Event ID 1196 (resource failure) and 1069 (cluster resource could not be found).
Don't manually delete resources — Always use Failover Cluster Manager or PowerShell to remove cluster objects. Deleting a resource from the registry or disk will orphan its GUID.
Test failover monthly — Run a manual failover of each group. This catches DNS and dependency issues before they become emergencies.
Stay current on patches — Microsoft fixed a bug in Windows Server 2019 where cluster resources went missing after KB5006744. Apply the latest cumulative update.

That's it. Go fix that 0x0000138F and get back to something better than cluster troubleshooting.