Fix ERROR_RESOURCE_NOT_AVAILABLE (0X0000138E) on Windows Cluster

When This Error Hits

You'll see ERROR_RESOURCE_NOT_AVAILABLE (0X0000138E) right after a node reboot or a manual failover attempt. The cluster resource — could be a file share witness, a generic application, or a disk — shows as Offline or Pending in Failover Cluster Manager. You try to bring it online, but it fails immediately with this error. The event log typically shows Event ID 1069 or 1196 alongside it. I've seen this most often on Windows Server 2016 and 2019 clusters, but it happens on 2012 R2 too.

Root Cause

The culprit here is almost always a dependency chain issue. The resource can't start because something it relies on isn't ready or is hanging. Common triggers:

A storage resource (disk, volume) didn't mount in time.
A network name resource is stuck in a pending state because DNS registration took too long.
The resource's DLL or service crashed during an earlier attempt, leaving it in limbo.
Cluster heartbeat timeouts on a slow node.

Don't bother restarting the whole cluster service — that rarely fixes a single resource. The issue is specific to that resource's state machine.

Fix: Step-by-Step

Check the resource dependencies — Open Failover Cluster Manager, right-click the failed resource, select Properties, go to the Dependencies tab. Make sure each dependency is online and healthy. If a dependent resource is also offline, fix that one first. No shortcuts here.
Force the resource offline then back online — Run this PowerShell on the cluster node that owns the resource:
```
Get-ClusterResource "YourResourceName" | Stop-ClusterResource -IgnoreLocked
Get-ClusterResource "YourResourceName" | Start-ClusterResource
```
The -IgnoreLocked flag bypasses any stuck pending state. If it won't stop, add -Force but be careful — force can leave orphaned processes.
Check the cluster log — Generate a fresh log with:
```
Get-ClusterLog -Destination C:\ClusterLogs -TimeSpan 10
```
Open the log and search for your resource name. Look for lines like Resource state change or Online thread. A common pattern: the resource tries to go online, hits a dependency timeout, and the thread aborts with 0X0000138E.
If it's a disk resource — Verify the disk is accessible on the owning node:
```
Get-ClusterResource "Cluster Disk X" | Get-ClusterParameter
```
Check if the disk is missing from Disk Management. If it's there but not assigned a drive letter, assign one manually. Cluster disks hate missing drive letters.
If it's a network name resource — Clear DNS cache on the node and re-register:
```
ipconfig /flushdns
Register-ClusterResource -Name "YourNetworkName"
```
Wait 60 seconds, then try the online step again.
Restart the Resource Hosting Subsystem (RHS) — This is my go-to when nothing else works. It kills and restarts the process that hosts the resource. On the node owning the resource, run:
```
Get-ClusterResource "YourResourceName" | Get-ClusterOwnerNode
Stop-Service -Name ClusSvc -Force
Start-Service -Name ClusSvc
```
I know restarting the whole cluster service sounds drastic, but it's often faster than chasing individual resource hangs.

If It Still Fails

You've done the steps above and the resource still won't come online? Time to dig deeper:

Run Cluster Validation — Run Validate-Cluster from Failover Cluster Manager or PowerShell. It'll check storage, network, and system configuration. A failed validation test will point to hardware or driver issues.
Check for antivirus conflicts — I've seen McAfee and Symantec block cluster resources during failovers. Temporarily disable real-time scanning on the cluster node, then retry. If that fixes it, add exceptions for cluster processes (ClusSvc.exe, RHS.exe).
Look at the resource DLL — For generic applications, the DLL might be corrupt or mismatched with the cluster version. Re-register it with regsvr32 or reinstall the application.
Check the cluster heartbeat — If multiple resources fail on the same node, check network connectivity between cluster nodes. A ping test isn't enough — run Test-ClusterNetwork to verify the heartbeat network.

If none of that works, you're looking at a deeper issue — possibly a corrupt cluster database. That means rebuilding the cluster. But I'd bet my lunch that one of the steps above will get you sorted. This error is stubborn, but it's almost always fixable without a full rebuild.