ERROR_RESOURCE_PROPERTIES_STORED 0x000013A0 Fix

0x000013A0 is a cluster resource state code, not a crash. It appears in Failover Cluster logs when a resource's property store can't be read or written.

Quick answer: ERROR_RESOURCE_PROPERTIES_STORED (0x000013A0) means the Cluster Service couldn't persist or read a resource's stored properties — usually the Cluster Hive in the registry is locked, corrupt, or a resource DLL threw during serialization. Restart the Cluster Service first, then check permissions on HKLM\Cluster.

This one trips people up because it sounds like a generic Windows error. It's not. 0x000013A0 only shows up in Failover Cluster environments — usually in Cluster.log or the Failover Cluster Manager event log — when a resource (an IP address, a file share, a generic service, an SQL instance) can't write its own config back to the cluster's property store. I've seen this bite a two-node SQL Server 2016 cluster after someone ran a Windows Update on one node and not the other, and the resource DLL versions drifted. The resource kept flapping, the event log filled with 0x000013A0, and the DBA kept opening tickets blaming the storage. It wasn't the storage.

The property store itself lives in HKLM\Cluster\Resources\<GUID> under the Cluster Hive. When a resource comes online, the Resource Hosting Subsystem (RHS.exe) calls into the resource DLL, which reads its saved properties from that hive, then writes back any state changes. If the hive is read-only, ACL-broken, or the Cluster Service lost its lock on it, you get 0x000013A0. Same story if the resource DLL is a different build than the Cluster Service expects — it writes a blob the service can't parse, and the property write fails.

Fix it in order — don't skip steps

Identify the failing resource. Open Failover Cluster Manager, or run:
```
Get-ClusterResource | Where-Object {$_.State -ne 'Online'} | Select Name, State, OwnerNode
```
Note the resource name. That's your target for the rest of this.
Check the Cluster log. Don't guess. Pull the log and grep for the code:
```
Get-ClusterLog -Destination C:\Temp -TimeSpan 30
Select-String -Path C:\Temp\*Cluster.log -Pattern '13A0'
```
You'll see the resource name and the DLL that threw. Write both down.
Restart the Cluster Service on the owning node. Not the whole node — that's overkill and it's what everyone does wrong.
```
Stop-Service ClusSvc
Start-Service ClusSvc
```
Wait 60 seconds, then check resource state. If it comes online and stays online for 10 minutes, you're done — it was a transient lock.
Check the Cluster Hive ACLs. This is where most cases actually live. Open regedit, navigate to HKLM\Cluster, right-click → Permissions. The NT AUTHORITY\SYSTEM account needs Full Control. So does the Cluster Service SID. I've seen security hardening scripts strip SYSTEM's rights on HKLM\Cluster because some auditor flagged it. That breaks everything.
If the hive looks fine, verify the resource DLL versions. On every node:
```
Get-ChildItem "$env:SystemRoot\Cluster" -Filter *.dll | Select Name, LastWriteTime
```
Compare across nodes. If node 1 has a resource DLL dated March and node 2 has one dated November, you've got a patching mismatch. Apply the same cumulative update to every node, then reboot them one at a time.
Bring the resource online manually.
```
Start-ClusterResource -Name "<YourResourceName>"
```
If it fails again, immediately run Get-ClusterLog again — the fresh log will show the exact failure point.

If that didn't work

Take the resource offline, remove it, and recreate it. Yes, really. This is faster than chasing a corrupt property blob for three hours. Save the settings first — IP, share path, dependencies — then:

Stop-ClusterResource -Name "<YourResourceName>"
Remove-ClusterResource -Name "<YourResourceName>"
Add-ClusterResource -Name "<YourResourceName>" -ResourceType "<Type>"

Recreate it with the same settings and dependencies. The new resource gets a fresh GUID and a clean property store entry.

If it's a Generic Service resource, also check the service account. A service running as a domain account that lost its cluster logon rights will fail property writes. Run cluadmin.exe → right-click the cluster → Properties → check the account has Log on as a service and Adjust memory quotas.

Real one from last month: a client's print cluster kept throwing 0x000013A0 every time the print spooler resource failed over. Turned out a leftover Group Policy pushed a registry policy file that locked HKLM\Cluster\Resources to read-only on one node. The policy had been removed from AD months earlier but the local Registry.pol file still applied it. gpresult /h showed nothing. Deleting C:\Windows\System32\GroupPolicy\Machine\Registry.pol and rebooting fixed it.

Prevention

Three things keep this from happening again. Patch every node in the cluster on the same maintenance window — never one node and "the rest next week." Audit your security baselines so they don't touch HKLM\Cluster; add it to the exclusion list if you're running CIS or STIG hardening. And monitor the Cluster event log for 0x000013A0 — one occurrence is noise, three in an hour means a resource is about to go down for good.

Back up the Cluster Hive weekly. It's a two-line scheduled task and it's saved me more than once:

reg export HKLM\Cluster C:\Backups\cluster-hive-%date%.reg /y

You won't need it. Until you do.