Fixing ERROR_CLUSTER_RESNAME_NOT_FOUND (0x000013D8)

Cause #1: The resource name doesn't match what the DLL expects

This is the one you'll hit 90% of the time. The error 0x000013D8 — ERROR_CLUSTER_RESNAME_NOT_FOUND — means the Failover Cluster Manager handed a resource name to the resource DLL, and the DLL said “I don't have a resource by that name.” The DLL might be a generic script, a File Share witness, or a custom resource type. The name mismatch is almost always a typo or a leftover entry from a deleted resource.

What's actually happening

When you run a command like Get-ClusterResource or try to bring a resource online, the Cluster service passes the resource name to the DLL's Online or LooksAlive entry point. The DLL maintains its own internal list of resource names. If the name passed doesn't match any name in that list, you get 0x000013D8. This happens most often with custom resources (like those using the ResourceType set to a third-party DLL) or after a failed resource migration.

The fix

1. Open PowerShell as Administrator on a cluster node.
2. Run Get-ClusterResource to see all resources. Look for the resource throwing the error. Check its ResourceType — that's the DLL in charge.
3. Run Get-ClusterResource "YourResourceName" | fl * to see all properties. Pay attention to Name and ResourceType.
4. If the resource name looks correct, the DLL itself could have stale data. For a generic script or service resource, the DLL stores resource names in HKLM\Cluster\Resources\{GUID}\Parameters. Navigate there in Regedit and check the Name value under that GUID. It must match exactly, including case on some DLLs.
5. If they don't match, update the registry entry to the correct name, or rename the cluster resource to match the DLL's internal name using Get-ClusterResource "OldName" | Rename-ClusterResource -NewName "CorrectName".
6. Restart the Cluster service on the node: Stop-Service ClusSvc; Start-Service ClusSvc.

I've seen this exact scenario with a custom VMware VDP resource where the name had a trailing space in the DLL's registry. Trimming it fixed everything.

Cause #2: Orphaned resource entries in the cluster database

This is the second most common — a resource was removed from the cluster via Remove-ClusterResource, but the cluster database still holds a reference to it in the resource type's private properties. The DLL tries to enumerate its resources, finds the orphan, and barfs because the resource itself is gone.

The fix

1. First, confirm the resource is actually gone: Get-ClusterResource | Where-Object {$_.State -eq 'Offline'}. If you see a resource named something like orphaned-resource-guid-{...}, that's your culprit.
2. Remove it properly: Get-ClusterResource "ThatOrphanedName" | Remove-ClusterResource -Force. The -Force flag bypasses the resource DLL check.
3. If the orphan doesn't show up in Get-ClusterResource but the error persists, the reference lives in the cluster configuration. Use the Cluster Database Editor (clustered.exe from the Windows SDK) or PowerShell with Get-ClusterResourceType to inspect the resource type's private properties. Look for a ResourceNames multistring value that includes the missing name. Remove it.
4. Run a cluster validation: Test-Cluster. This often surfaces deeper inconsistencies.

A client of mine had this after a failed SQL Server 2019 FCI uninstall. The resource was gone, but the SQL Server resource DLL (sqsrvres.dll) still had an entry for it in its private registry hive. Removing that entry from HKLM\Cluster\Resources\{GUID}\Parameters under the resource type's GUID fixed the error on all nodes.

Cause #3: The resource DLL is the wrong version or corrupt

Less common, but when it happens, it's a pain. The DLL expects a certain name format (maybe all uppercase, or with a prefix), but your resource name doesn't match. Or the DLL is from an older build and doesn't recognize a newer property. This pops up after a cluster rolling upgrade from Windows Server 2016 to 2019 or 2022.

What's actually happening

The resource DLL's ResourceControl function receives a CLUSCTL_RESOURCE_GET_NAME request and returns a name the Cluster service doesn't expect — or the DLL's internal name table got corrupted during the upgrade. The 0x000013D8 is thrown when the Cluster service tries to match the returned name against its own list.

The fix

1. Check the DLL version: (Get-Item "C:\Windows\Cluster\res*.dll").VersionInfo.FileVersion. Compare across all nodes. They should match.
2. If they don't, reinstall the cluster feature or the application that owns the DLL. For a generic resource, you can re-register the DLL: regsvr32 /u C:\Windows\Cluster\resgeneric.dll then regsvr32 C:\Windows\Cluster\resgeneric.dll.
3. If the DLL is from a third party (like a storage vendor), reinstall their cluster provider. I've seen Dell EqualLogic and NetApp resources break this way after a Windows update replaced the DLL with a generic one.
4. Still broken? Remove and recreate the resource type: Remove-ClusterResourceType -Name "YourType"; Add-ClusterResourceType -Name "YourType" -Dll "C:\Path\To\Your.dll". This is drastic — it nukes all resources of that type — so back up the cluster first.

Quick-reference summary table

Start with Cause #1. It's the most frequent and the easiest to check. If that doesn't work, move to Cause #2. Cause #3 is rare but worth checking if you're on a mixed-version cluster or just applied a Windows update.