Cluster resource stuck offline? Fix ERROR_RESMON_ONLINE_FAILED

Yeah, this one’s annoying.

You try to bring a cluster resource online — maybe a file share witness, a generic service, or a disk — and instead of working, you get a big fat 0x0000139A with ERROR_RESMON_ONLINE_FAILED. The resource monitor itself bailed. Been there. Had a client last month whose entire SQL Server availability group went dark because of this exact error. Here’s the real fix.

Step 1: Restart the Resource Monitor service

This is the fastest test and solves maybe 40% of cases. The cluster resource monitor runs as a separate process (usually RHS.exe). If it hangs or crashes, the resource can’t come online even if the underlying resource is fine.

1. Open Failover Cluster Manager or just use PowerShell.
2. Kill the resource monitor for the affected resource group. In PowerShell:

Get-ClusterResource "YourResourceName" | Stop-ClusterResource
Start-Sleep 2
Start-ClusterResource "YourResourceName"

Don’t just stop and start the resource — that often fails again. Instead, restart the Cluster Service on the node that owns the resource group. Painless if you have a multi-node cluster:

Stop-Service ClusSvc
Start-Service ClusSvc

After the cluster service comes back, try bringing the resource online again. 9 times out of 10, it works.

Step 2: Check permissions on the resource

The resource monitor runs under the local system account on each node. If the underlying resource (file share, registry key, disk drive) has broken permissions, the monitor can’t even start it. Common culprit: a file share witness where someone changed NTFS permissions on the witness share.

Check the cluster log for clues. Run:

Get-ClusterLog -Destination C:\ClusterLogs

Open the log for the node where the resource was trying to come online. Look for lines with RHS and ERROR_RESMON_ONLINE_FAILED. You’ll see something like Access Denied or Object not found. Fix the permissions issue (usually grant SYSTEM full control on the share and underlying path).

Step 3: Check dependencies

I’ve seen this error pop up when a resource depends on something that was removed or renamed. For example, a clustered generic service depends on a storage disk that got moved to a different cluster group. The resource monitor tries to bring the dependency online first, fails, and reports ERROR_RESMON_ONLINE_FAILED.

• Right-click the resource → Properties → Dependencies tab.
• Check every dependency is still present and online in Failover Cluster Manager.
• If a dependency is missing, remove it from the dependency list first, then try bringing the resource online alone. If it works, rebuild the dependency chain.

Less common variations

Corrupted Cluster Database

Yes, it happens. The cluster database gets a corrupt entry for a resource. Symptoms: the error shows up on multiple nodes, and rebooting the cluster service doesn’t help. Fix: evacuate all resources from the node, then run Get-ClusterResource | Remove-ClusterResource for the bad resource only. Recreate it fresh. I had to do this for a client running Windows Server 2016 — the resource monitor kept failing on a generic script resource that had a tiny error in its script path.

Resource Monitor process stuck in a loop

Sometimes RHS.exe enters a state where it starts, fails, restarts, fails again. You’ll see the error multiple times in quick succession. In this case, restarting the cluster service doesn’t help because the corrupt process restarts automatically. Kill RHS.exe forcefully from Task Manager (or taskkill /f /im RHS.exe), then restart the cluster service. That resets the resource monitor pool completely.

Third-party antivirus interference

Yeah, antivirus can block cluster processes. If you’ve exhausted everything above, check your antivirus logs. Trend Micro and McAfee have both caused 0x0000139A errors for me. Exclude %SystemRoot%\Cluster\ directories and all RHS.exe processes from real-time scanning.

Prevention tips

• Patch your nodes — Microsoft fixed several resource monitor race conditions in cumulative updates for Windows Server 2019 and 2022. Stay on current.
• Don't rename dependencies after creation. Cluster stores the dependency by name, not by ID. Rename a disk in Disk Management, and the resource monitor can't find it.
• Set resource timeout to 120 seconds (default is 60). Some resources take longer to initialize, especially if they're starting a service. In the resource's Properties → Advanced Policies tab, change Pending Timeout to 120.
• Log everything. Enable verbose cluster logging on all nodes: Get-ClusterResource | Set-ClusterResource -LogLevel Verbose. Then when the error happens again (it will), you’ll have the data to fix it fast.

This error is almost always a resource monitor crash — not a real resource failure. Start with the service restart, then check permissions and dependencies. If you’re still stuck, the cluster logs will tell you exactly what broke. Don't rebuild the whole cluster for this one.