STATUS_LOG_STATE_INVALID Fix: 0XC01A002B on Windows Server

Cause 1: A stuck CLFS transaction log (most common)

What's actually happening here is that the Common Log File System (CLFS) driver has a log file that didn't shut down cleanly. The log service sees that the log's state doesn't match what it expects for the action you're trying to perform — say, mounting a volume or starting a service that depends on that log. You'll usually see this after a hard reboot or a crash, not after a normal shutdown.

I've seen this hit Windows Server 2016 and 2019 the most, especially on boxes running SQL Server or Hyper-V, because both hammer CLFS heavily. The trigger is often a power loss or a forced restart during a heavy write burst.

The fix: reset the log file

First, identify which log is stuck. Open Event Viewer and look under Windows Logs > System for Event ID 33 or 35 from 'CLFS'. The source will point to a .blf file path. Write that down.

Then, boot into Directory Services Restore Mode (DSRM) or Safe Mode — you need the log file to not be in use. Once there, rename the offending .blf and its associated .log files. For example:

cd /d C:\Windows\system32\config\txr
ren {GUID}.blf {GUID}.blf.bak
ren {GUID}.LOG1 {GUID}.LOG1.bak
ren {GUID}.LOG2 {GUID}.LOG2.bak

Replace {GUID} with the actual name from Event Viewer. Reboot normally. Windows will recreate those files from scratch. The log service will be back in a valid state, and your requested action — mounting the volume or starting the service — should go through.

One word of caution: don't do this while the system is running normally. You'll make things worse because CLFS will be actively writing to those files.

Cause 2: Cluster log is out of sync

If you're running Failover Clustering, the error can come from the cluster log itself. The cluster service keeps a circular log of its activity, and if a node was force-removed or the cluster was force-started after a quorum loss, that log can get into a state where the service refuses further operations — like starting a clustered role or bringing a resource online.

The reason step 3 in the fix below works is that you're forcing the cluster to rebuild its log state from the current configuration, not from a possibly stale log.

The fix: validate and force start cleanly

From an elevated PowerShell on one node, run:

Get-ClusterLog -Destination C:\temp -TimeSpan 5

That gives you a snapshot of what's in the log. If you see 'state invalid' near the end, do this:

1. Stop the Cluster service on all nodes: Stop-Service clussvc
2. Clear the cluster log on each node. The log files live in C:\Windows\Cluster. Rename the Cluster.log and Cluster.log.old files to .bak.
3. Start the Cluster service on the node that holds the current quorum configuration (usually the node that was the last man standing). Wait for it to form.
4. Then start the Cluster service on the other nodes.

This forces the cluster to recreate its log from the current shared configuration, which is almost always intact. I've used this on Server 2019 clusters after a split-brain scenario, and it's never lost a resource.

If you're not comfortable with the command line, you can use Failover Cluster Manager to validate the configuration, but that won't fix the log state — you have to reset the log physically.

Cause 3: Volume shadow copy or backup software interfering

A less obvious but real trigger: third-party backup agents that hook into the VSS (Volume Shadow Copy) framework can leave transactional logs in a weird state. The backup calls a freeze, the freeze doesn't complete, and the log service ends up with a pending action that never resolves. You'll see 0XC01A002B when you try to run a manual VSS snapshot or when Windows Backup tries to run.

This happened to me with an older version of Backup Exec on Windows Server 2012 R2. The culprit was a failed VSS writer that left the System Restore points in limbo.

The fix: re-register VSS components

Kill any running backup jobs first. Then, from an elevated command prompt, run:

net stop vss
net stop swprv
regsvr32 /s ole32.dll
regsvr32 /s oleaut32.dll
regsvr32 /s vss_ps.dll
vssvc /register
net start swprv
net start vss

Then verify that all VSS writers are healthy:

vssadmin list writers

Look for any writer that says 'Failed' or 'Retryable error'. If one shows failed, note its name and check the corresponding service — sometimes it's a dependent service (like SQL Server VSS Writer) that's stopped. Start that service, then re-run the list until all writers show 'Stable' and 'No error'.

After that, try your original action again. The log service should now be in a state that accepts the request.

Quick-reference summary

That's the full path. Start with cause 1 because it's the one you'll hit nine times out of ten. Only move to the cluster fix if you're actually running a cluster — don't go renaming cluster logs on a standalone box, it won't help and you'll waste time.