0x171C cluster string termination error fix

You're here because your cluster service threw 0x171C and you're losing time.

I've seen this exact error on Windows Server 2019 and 2022 clusters, usually after a partial failover or a manual edit of cluster resources. The culprit is almost always a corrupt string in the registry under the cluster's resource properties. Don't bother with a full cluster rebuild or reinstalling the role — that's overkill. Here's the fix.

The fix: delete the bad resource

Open PowerShell as admin. Run this to find the resource with the broken string:

Get-ClusterResource | Where-Object {$_.State -ne 'Online'} | Format-Table Name, State

Look for any resource that's stuck in a failed state or offline. That's your problem child. Note its name.

Now, remove it:

Remove-ClusterResource -Name "YourBadResourceName" -Force

Replace "YourBadResourceName" with the actual name. The -Force flag skips prompts. If the resource is shared (like a disk), you'll need to remove dependencies first. Run:

Get-ClusterResource -Name "YourBadResourceName" | Get-ClusterResourceDependency | Remove-ClusterResourceDependency

Then remove again. After that, restart the Cluster service on all nodes:

Restart-Service -Name ClusSvc -Force

Check the event log — the 0x171C should be gone. Re-add the resource cleanly through Failover Cluster Manager.

Why this works

The 0x171C error means the cluster service read a registry value that ends without a null terminator. This happens when someone (or a script) modifies a resource's properties and forgets to close the string properly. The registry key is under HKLM\Cluster\Resources\{GUID}\Parameters. A single corrupt string can take down the whole service. Deleting the resource forces the cluster to purge that key entirely. Re-adding it creates a fresh, properly formatted entry.

Less common variations

Sometimes the error shows on a specific disk resource, not a generic one. Check the event ID 1146 alongside the 0x171C. If it's disk-related, use this command to see the disk's properties:

Get-ClusterResource -Name "Cluster Disk 1" | Get-ClusterParameter

Look for a parameter with a blank or garbled value. If you find one, you can sometimes fix it by resetting the parameter instead of nuking the whole resource. Use:

Get-ClusterResource -Name "Cluster Disk 1" | Set-ClusterParameter -Name "DiskId" -Value ""

But honestly, I've never had luck with that — the string is already corrupt in the registry. I always just delete and recreate. Less risk of leaving a hidden bad string.

Another rare case: the error appears after a Windows update. Microsoft KB 5008218 caused this on Server 2019. If the update is recent, roll it back first, then do the cleanup above.

Prevention

Stop editing cluster resources manually through regedit. I know it's tempting when things break, but that's how you get here. Always use PowerShell cmdlets or GUI tools. Set up alerts for event ID 1146 — catch the bad string early before it takes down the cluster. Also, test scripts that modify cluster resources in dev first. A missing null terminator in a scripted value will bite you.

Final tip: keep your cluster nodes on the same Windows version and cumulative updates. Mixed levels increase the chance of string format mismatches. If you see this error more than once, run a cluster validation report:

Test-Cluster -ReportFilePath C:\ClusterValidation.html

Look for warnings about registry data integrity. That'll point you to the exact key. But for most of you reading this, just delete the bad resource and move on. You've got better things to do than chasing corrupt strings.