Fix ERROR_QUORUMLOG_OPEN_FAILED (0X000013A4) Fast

You've hit 0X000013A4 and your cluster's down

Yeah, that sucks. The cluster service won't start, event viewer shows ERROR_QUORUMLOG_OPEN_FAILED with code 0X000013A4, and you're staring at a dead SQL Server or file server. I've been there — had a client lose their entire ERP system for three hours because of this. Let me walk you through the fix that actually works.

The quick fix: rebuild the quorum witness

Most of the time, this error means the quorum witness (usually a file share or disk) is corrupt or inaccessible. Here's what to do:

Check disk space on the witness drive. If it's a file share witness, log into the server hosting the share and run dir on the witness path. If the drive is full (happens more than you'd think), free up space or move the witness to a different volume.
Delete and recreate the witness. On any node in the cluster, open PowerShell as Administrator and run:
```
Stop-Service -Name ClusSvc -Force
Remove-Item -Path 'C:\ClusterStorage\Volume1\witness.log' -Force
Start-Service -Name ClusSvc
```
Adjust the path to match your witness location. For a file share witness, delete the witness file on the share server instead.
Rebuild quorum configuration. After the service starts, run:
```
Set-ClusterQuorum -FileShareWitness \\Server\Share -Credential (Get-Credential)
```
Or use -DiskWitness if using a disk.

Had a client last month whose print queue died because of this. Ran those three steps — cluster was back in 2 minutes.

Why does this work?

The quorum log (witness.log or the disk witness region) stores cluster state. When it gets corrupted from a sudden power loss, disk failure, or even a failed backup that locks the file, the cluster service can't read it. Deleting that file forces the cluster to create a fresh log from the remaining node's configuration. The 0X000013A4 error is literally Windows saying "I can't open the quorum log file."

A full disk on the witness share is the #1 cause I see — SQL Server transaction logs or user files fill up the volume, the witness can't write, and boom — the log fails to mount.

Less common variations of this problem

1. Antivirus scanning the witness file

Some antivirus software locks the witness.log file while scanning. Check your antivirus logs and add an exclusion for the witness path (e.g., C:\ClusterStorage\* or \\Server\Share\witness*). Disable real-time scanning temporarily to test.

2. File share permissions changed

If someone modified NTFS permissions on the share, the cluster computer object (DOMAIN\CLUSTERNAME$) might lose access. Re-run the Set-ClusterQuorum command with explicit credentials, then verify permissions include Full Control for the cluster object.

3. Corrupted disk witness partition

With disk witnesses, the partition itself can go bad. Run chkdsk /f on the disk, then remove and re-add it as witness via Failover Cluster Manager. If that fails, you might need to format and recreate the partition — but only as a last resort.

4. Cluster service database corruption

Rare, but I've seen it. If the witness fix doesn't work, the service database (%SystemRoot%\Cluster\ClusDB) might be corrupt. You'd need to restore the cluster from backup or force-quorum with the last known good node using Start-Service -Name ClusSvc -ArgumentList '/forcequorum'.

Preventing this from happening again

Three things I tell every client after fixing this:

Monitor disk space on witness drives. Set an alert at 80% full. That share or volume must never fill up.
Exclude cluster paths from antivirus. Add exclusions for %SystemRoot%\Cluster\* and C:\ClusterStorage\* (adjust for your witness location).
Take regular cluster backups. Use Windows Server Backup or a third-party tool to back up the cluster configuration (including the quorum database). This lets you restore quickly if the log gets corrupted again.

That's it. No magic, no fluff. Rebuild the witness, check space, and lock down permissions. Your cluster will be back online before your boss even notices.