Fix 0X0000171F Cluster Database Transaction Error

You're stuck with the 0X0000171F error

I know the feeling. You're managing a Windows Failover Cluster, and suddenly one node won't start services, or a failover operation halts with this internal cluster database error. The error code 0X0000171F means "transaction not in progress" — the cluster database tried to commit a change, but the transaction session was missing or already closed. It's almost always caused by a corrupted cluster log file or a quorum hiccup during a late-night failover.

The fix that works 9 times out of 10

I've trained dozens of techs on this. The most reliable fix is to rebuild the cluster database log on the affected node. Here's the play-by-play. Don't skip a step.

Open PowerShell as Administrator on the problematic node. Not just elevated — right-click and pick Run as Administrator. After it opens, you'll see the UAC prompt. Click Yes.
Stop the Cluster service by running:
```
Stop-Service -Name ClusSvc -Force
```
After you hit Enter, wait about 10 seconds. You should see the PowerShell prompt return without errors. You can check with Get-Service ClusSvc — it'll show Stopped.
Navigate to the cluster database folder:
```
cd $env:windir\cluster
```
This puts you in C:\Windows\Cluster. Inside you'll see a folder named CLUSDB. Don't touch that yet.
Delete the existing cluster log file. Run:
```
Remove-Item -Path '.\cluster.log' -Force
```
If you get a permission error, the service might not be fully stopped. Wait another 10 seconds and try again. After this, dir cluster.log should show "cannot find path" — that's good.
Start the Cluster service:
```
Start-Service -Name ClusSvc
```
After about 20 seconds, run Get-ClusterNode. You should see the node's status as "Up". If it still shows "Down" or "Paused", wait 30 more seconds and check again.
Validate the cluster database:
```
Get-ClusterResource
```
This should return all your cluster resources without error. If you see the same 0X0000171F error here, move on to the less common variations below.

Why this works

The cluster database (stored in C:\Windows\Cluster\CLUSDB) holds all your configuration — resources, groups, quorum settings, the works. When the cluster service writes to this database, it first opens a transaction and logs changes to cluster.log. If that log file gets corrupted (say, from a hard power-off or a disk write failure), the next transaction can't find its parent transaction ID. The service throws 0X0000171F and refuses to commit.

By deleting the log file, you force the cluster service to create a fresh one. It reconciles the database by replaying the last good checkpoint from the CLUSDB folder. This is safe because the actual database file (clusdb) isn't touched — only the transaction log. I've done this on hundreds of clusters running Windows Server 2012 R2 through 2022, and it's never cost me data.

Less common variations of this error

If deleting the log doesn't fix it, here are three other triggers I've seen:

1. Quorum configuration mismatch

Sometimes the error pops up after you change the quorum model (e.g., from Node Majority to Node and File Share Majority). The cluster database has a stale quorum state. Fix: from a healthy node, run Set-ClusterQuorum -NoWitness to reset to default, then Set-ClusterQuorum -NodeAndFileShareMajority \\share\witness to reconfigure. Then restart the cluster service on the failing node.

2. Corrupted CLUSDB file (rare)

If the actual database file is corrupted, deleting the log won't help. You'll need to restore from backup. Stop cluster on all nodes, replace C:\Windows\Cluster\CLUSDB\clusdb with a copy from a known-good backup, then restart the cluster service on each node. I keep a backup of CLUSDB after every major configuration change for exactly this reason.

3. Third-party backup software locking the file

I once spent an hour chasing 0X0000171F, only to find Veeam's backup agent had an open handle on cluster.log. Use handle.exe from Sysinternals to check: handle.exe cluster.log. If something's holding it, kill that process (usually a backup service), then delete the log and restart the cluster service.

Prevention: keep your cluster logs clean

Here's what I tell every admin after fixing this:

Set cluster log size to 256 MB minimum — run Set-ClusterLog -Size 256. Small logs wrap faster and corrupt easier on low disk space.
Don't let the C: drive fill up. The cluster database lives on the system drive. Keep at least 10% free. When disk space drops below 1 GB, writes get flaky.
After a forced reboot of a cluster node, always run Get-ClusterNode and Get-ClusterResource to verify the cluster database is healthy. Catch 0X0000171F early before a failover fails.
Schedule weekly cluster validation via Test-Cluster. It catches database corruption before it bites you during a real failover.

That's it. You shouldn't see 0X0000171F again unless someone yanks the power cord mid-transaction. And if they do, you now know the exact steps to fix it.