Fix 0xC01A0002 Log Parity Error on Windows Servers

Quick answer

For advanced users: boot into WinRE, run chkdsk /f on the system drive, then delete the affected .blf and .regtrans-ms files (if it's a registry log) or the specific CLFS log for the service.

If you're here, something on your server just threw 0xC01A0002 — STATUS_LOG_SECTOR_PARITY_INVALID. That's the Common Log File System (CLFS) driver complaining that a log sector's parity bits don't match the actual data. It's not a subtle issue. It usually means the log file got corrupted, often after an unclean shutdown, a disk write failure, or a failing disk that's silently dropping sectors. I've seen this on Windows Server 2016 and 2019 boxes, especially after a power blip or a forced reboot of a VM.

Don't panic. You won't need to reinstall the OS—most of the time. The fix is targeted: find which log is bad, clear it, and let the service rebuild. Here's the step-by-step.

Before you start

You need administrative rights and a backup. If you can't boot normally, you'll need the installation media or WinRE. Also, identify which component is failing. Check the Event Viewer for the source—it'll say "CLFS" or name a specific service like Registry or a database.

Fix steps

Boot to Safe Mode or Windows Recovery Environment. If the server crashes on boot, use Shift + Restart or the install disk. Once in WinRE, open Command Prompt.
Run CHKDSK to rule out disk corruption. At the prompt, type chkdsk /f /r on the system drive (usually C:). Let it complete—this catches the underlying cause. If it finds bad sectors, replace the disk after the fix.
Locate the corrupt log. If the error mentions a specific path, note it. If it's a registry log, you'll see files like C:\Windows\System32\config\SYSTEM with .blf and .regtrans-ms extensions. For other services, look in C:\Windows\System32\config\ or the service's own data folder.
Clear the log. For registry logs, rename or delete the .blf and .regtrans-ms files. Use del /f /q C:\Windows\System32\config\SYSTEM*.blf and SYSTEM*.regtrans-ms. For other CLFS logs, delete the .blf file and its associated .log container. The system recreates them on next boot.
Reboot normally. Windows will rebuild the log. Check Event Viewer to confirm the error is gone.

If that doesn't work

Don't bother with registry hacks—that rarely helps. Instead, try these in order:

Restore from a recent backup. If you have a system state backup, restore just the corrupted log files. That's faster than debugging.
Use System File Checker. Run sfc /scannow from an admin Command Prompt. It won't fix CLFS logs directly, but it will repair system files that might be triggering the issue.
Disable and re-enable the service. If the error is tied to a specific service like the Windows Event Log, stop it, rename its log folder, and start it again. The service recreates the logs.
Check for pending updates. A known bug in older builds caused this during heavy I/O. Install the latest cumulative update for your Windows Server version.

Prevention tips

This error is a symptom of deeper problems. Here's how to keep it from happening again:

Use UPS or a proper VM snapshot strategy. Hard power-offs are the number one cause of log corruption.
Monitor disk health. Use wmic diskdrive get status or your vendor's tool. If SMART data shows reallocated sectors, replace the drive before it gets worse.
Test your backups regularly. You don't want to discover they're useless when you're knee-deep in this.
Keep Windows Server patched. Microsoft has fixed CLFS issues in several updates, so apply them promptly.

One last thing: if you're running a database server (SQL Server, Exchange), this error can appear in their own log files. In that case, you might need to repair the database using its own tools—like REPAIR_ALLOW_DATA_LOSS for SQL—but only after you've verified the disk is healthy. You don't want to recover onto a dying disk.

That's it. You should be back up in under an hour, unless the disk is toast. If you're still stuck after these steps, the log file is likely beyond repair, and a system state restore is your cleanest option.