Fix Cluster Resource Dependency Not Found (0X0000138A)

I've seen this error confuse a lot of admins. You're setting up a cluster resource, or you're trying to bring one online, and you get slapped with ERROR_DEPENDENCY_NOT_FOUND (0X0000138A). It's frustrating because the error message doesn't tell you which dependency is missing. Let's fix it.

What causes this error

This error appears in Windows Server Failover Clustering (tested on Server 2016, 2019, and 2022). It happens when a resource references a dependency that doesn't exist in the cluster. Common triggers:

• You manually removed a resource (like a disk or IP address) that another resource depended on.
• A cluster validation or update process orphaned a dependency reference.
• You imported a cluster configuration from another system, and the GUIDs don't match.

The real fix is to find and delete the broken dependency, then re-add the required resource correctly.

Step-by-step fix

Step 1: Identify the resource with the bad dependency

1. Open Failover Cluster Manager on the node that owns the resource group.
2. In the left pane, expand the cluster name, then expand Roles.
3. Select the role (like "SQL Server (Instance1)" or "Hyper-V VM") that shows the error.
4. In the center pane, look at the Status column. The resource with the error will show a red X or say "Failed".
5. Right-click that resource and select Properties.

Step 2: Check the Dependencies tab

1. In the Properties window, go to the Dependencies tab.
2. You'll see a list of resources this resource depends on. Look for any entry that shows Resource not in cluster or a GUID that doesn't match anything in your cluster.
3. If you see a dependency listed that references a resource you can't find, that's your culprit.

Step 3: Remove the broken dependency

1. Select the bad dependency entry.
2. Click Remove. Do this for every orphaned dependency you see.
3. Click Apply — you should see a confirmation that the dependencies were updated.
4. Click OK to close the Properties window.

Step 4: Add the correct dependency back

1. Right-click the resource again and go to Properties > Dependencies.
2. Click Insert.
3. From the list, choose the correct resource that should be a dependency (for example, if it's a SQL Server resource, the dependency might be a specific disk or IP address).
4. Set the dependency mode if needed (usually "OR" or "AND" — most common is "AND" for multiple dependencies).
5. Click Apply, then OK.

Step 5: Bring the resource online

1. In Failover Cluster Manager, right-click the resource and select Bring Online.
2. Watch the status. It should change from "Failed" to "Online" within a few seconds.
3. If it still fails, repeat steps 3-4 and double-check you added the right dependencies.

Why this works

Cluster resources need to know their dependencies to start in the right order. For example, a SQL Server instance depends on the disk being available first. If the dependency reference points to a resource that's been deleted, the cluster can't validate the dependency chain, so it rejects the entire resource. Removing the orphaned reference clears that block. Adding the correct dependency re-establishes the proper startup order.

I've seen people try to fix this by restarting the cluster service or rebooting nodes. That doesn't work because the bad dependency is stored in the cluster database. You have to edit it out.

Less common variations

Sometimes the dependency isn't visually broken. The resource shows up in the list but fails anyway. That happens when the dependency resource itself is in a failed state but the error code still comes as 0X0000138A. In that case:

• Check the dependency resource's status first. If it's offline or failed, fix that resource first.
• If the dependency resource has its own missing dependencies, you might need to fix a chain of dependencies.

Another variation: You try to create a new resource and get this error during creation. That usually means the cluster database has a leftover reference from a previous failed attempt. Run this PowerShell command on the cluster node as an administrator:

Get-ClusterResource | Where-Object {$_.State -eq 'Failed'}

If you see a resource that shouldn't be there (like a leftover from an aborted creation), remove it:

Remove-ClusterResource -Name "NameOfResource"

Then recreate your resource fresh.

Prevention

Don't delete cluster resources without first checking what depends on them. Before you remove any resource:

• In Failover Cluster Manager, right-click the resource and go to Properties > Dependencies. Look at the Dependent resources tab at the bottom — that shows which resources rely on this one.
• If anything is listed, remove the dependency from the dependent resource first, or replace it with an alternative.

Also keep your cluster documentation current. I keep a simple text file listing each role and its resources with dependencies. When I need to remove something, I check that file first. Saves me from this exact headache.

Finally, always test your changes in a lab environment if you can. Clusters are sensitive to configuration changes. A small mistake can take down production workloads.