Fix ERROR_RESMON_CREATE_FAILED 0x00001399 Cluster Resource

What's This Error Telling You?

You'll see ERROR_RESMON_CREATE_FAILED (0x00001399) when a cluster resource—like a file share witness or a generic service—refuses to start. The cluster service itself reports it can't create the resource inside the Resource Monitor (RHS.exe). The message doesn't tell you WHY, which is the annoying part.

Here's the root cause in plain terms: The cluster Resource Monitor (the process that actually hosts and runs resources) either crashed, got stuck in a bad state, or lacks permission to create the specific resource type. Windows Server 2012 R2 through 2022 all hit this. I've seen it most often after a resource rename or a failed configuration change.

The fix flow below goes from least invasive to most. Stop when the resource starts cleanly.

Step 1 — 30-Second Fix: Check Resource Monitor Health

This is the quickest thing to try. The Resource Monitor might just be hung or processing an old state.

1. Open Failover Cluster Manager.
2. Right-click your cluster, select More Actions > List Resource Monitor State.
3. Look for any Resource Monitor listed as Not Running or Pending. If you see one that's stopped, that's your culprit. If all are running fine, move to Step 2.
4. In the same window, you can right-click the failing resource and choose Bring Online again. Sometimes that's enough to re-trigger creation cleanly.

Why this works (sometimes): The Resource Monitor process (RHS.exe) can get stuck holding a lock from a previous failed resource creation. Listing the state forces the cluster service to re-evaluate. It's a cheap win.

Step 2 — 5-Minute Fix: Restart the Resource Monitor

If the quick check didn't help, kill the stuck Resource Monitor process. This forces the cluster service to spawn a fresh one.

1. Open Task Manager as Administrator on the node hosting the resource.
2. Find all RHS.exe processes. You'll likely see one with high CPU or memory.
3. Right-click and End Task on each RHS.exe. Don't worry—Windows Cluster will restart them automatically.
4. Wait 30 seconds, then retry bringing the resource online in Failover Cluster Manager.

Warning: If you have multiple resources, killing RHS.exe resets ALL resources on that node. They'll restart cleanly, but you'll see a brief interruption. Do this during a maintenance window or outside peak hours.

Real-world trigger: This happens all the time after a resource's timeout setting gets changed while the resource is online. The old RHS.exe hangs onto the old config and can't create the new version.

Step 3 — 15+ Minute Fix: Registry Cleanup and Permission Reset

If restarting the monitor didn't stick, the problem is deeper. Usually a corrupt resource entry in the cluster database (registry hive) or insufficient permissions for the cluster service account.

3a. Check the Cluster Service Account Permissions

The cluster service runs as a domain account or LOCAL SYSTEM. That account must have Create File / Write Data and Read / Execute on %SystemRoot%\Cluster\ResourceMonitor\ and the cluster quorum path.

1. Open File Explorer, navigate to C:\Windows\Cluster\ResourceMonitor.
2. Right-click the ResourceMonitor folder, select Properties > Security.
3. Click Advanced. Verify the cluster service account (or NT AUTHORITY\SYSTEM) has Modify permission. If not, click Add, add the account, and grant Modify.
4. Do the same for the quorum witness folder if you use a file share witness. That folder is often on a separate server—check its NTFS permissions too.

Why step 3a works: The Resource Monitor needs to write temporary files when creating resources. If it can't write to its own folder, 0x00001399 is the generic failure. I've seen sysadmins lock this folder accidentally during security audits.

3b. Purge Stale Resource Entries from Registry (Advanced)

This is the nuclear option. Only do this if the resource is stuck in a failed state and nothing else works. You'll need to remove the resource and recreate it.

1. Open Registry Editor on one node of the cluster. Go to HKEY_LOCAL_MACHINE\Cluster\Resources.
2. Each subkey is a resource. Find the one with the error by matching the Name value.
3. Before you delete anything: export the entire Resources key (right-click > Export). You'll need this if you delete the wrong one.
4. Delete the subkey for the broken resource.
5. Back in Failover Cluster Manager, right-click Roles and choose Configure Role. Recreate the resource with the same settings.
6. Bring it online immediately afterward.

Warning: Deleting a resource from the registry removes it from the cluster database permanently. The cluster service won't know about it anymore—you must recreate it. Double-check you're deleting only the problematic resource.

Why step 3b works: The cluster database in the registry can develop orphaned entries from failed creations. The Resource Monitor sees these orphans and refuses to create a new instance because it thinks one already exists. Deleting the stale entry clears the block.

Summary Flow

You'll fix 90% of cases with steps 1 and 2. The remaining 10% need the registry cleanup. Don't skip step 3a if you're hitting this repeatedly—it's the silent culprit.