Fix STATUS_LOG_BLOCK_INVALID (0XC01A000A) - Windows Server

What you're dealing with

You open Event Viewer or a management tool and see STATUS_LOG_BLOCK_INVALID (0XC01A000A). The log service refuses to read or write to a log file. It's not a hardware failure most of the time — it's a software-level corruption inside a log block. Usually hits Windows Server 2019 or 2022 during unexpected shutdowns or disk I/O hiccups.

Quick fix — skip the fluff

Run chkdsk on the drive hosting the logs. Open an admin command prompt. Type chkdsk C: /f /r (replace C: with your log drive). Reboot. Let chkdsk run through — it'll take 10-20 minutes on a large disk. The /r flag finds bad sectors and repairs them. This fixes the underlying file system issues that corrupt log blocks.
Identify which log file is corrupted. Run wevtutil gl to list all logs. Look for logs that fail to open with error 0XC01A000A. The most common culprits: System, Application, Security, or Windows PowerShell logs.
Back up and delete the corrupted log file. For each broken log, run: wevtutil cl <logname>. Example: wevtutil cl System. This clears the log entries but keeps the log structure. If the log service still complains, stop the service first: net stop EventLog then delete the .evtx file directly from %SystemRoot%\System32\winevt\Logs\. Rename it to .bak before deleting — you might need it for forensics later.
Restart the log service. net start EventLog. Check Event Viewer — the error should be gone. If not, reboot the server.

Why this works

The real trigger here is a mismatching checksum inside a log block. The Windows Event Log uses a block-based format where each block has a CRC32 checksum. When the disk writes a block partially — say because of a power loss or a driver bug during a flush — the checksum no longer matches the data. The log service sees that mismatch and throws 0XC01A000A because it can't trust the block.

Chkdsk with /f /r fixes the file system metadata and remaps bad sectors, so future writes go to clean areas. But chkdsk doesn't fix the existing corrupted block inside the log file. That's why step 3 is necessary: you have to remove the corrupted .evtx file entirely. Clearing it with wevtutil works unless the corruption is severe enough that the service can't even open the file to clear it — then you need the direct file delete.

The reason step 3 works is that the log service recreates the .evtx file with a fresh header and no blocks. No corruption, no error.

Less common variations

Sometimes the error isn't in the standard logs but in a third-party application log. You'll see it happen with Microsoft-Windows-Hyper-V-Worker-Admin on Hyper-V hosts after a VM crashes hard. Same fix: find the .evtx file under the same winevt\Logs folder, rename it, restart the service.

On Windows Server 2016, there's a weird edge case where the log service itself has a memory corruption bug that writes garbage blocks. Microsoft fixed it in KB4013429 (March 2017 rollup). If you're seeing the error after a clean shutdown for no reason, check your Windows Update history. Missing that patch is the root cause — chkdsk won't help because the disk is fine.

Another variation: NTFS file system corruption on the log volume. The .evtx file looks fine in size but reading it returns all zeros. You'll get 0XC01A000A because the log service finds a block with checksum of 0x00000000. Cmd: fsutil dirty query C: if it says dirty, run chkdsk and reboot.

Prevention — keep your logs clean

Set max log size to a reasonable limit. Don't let logs grow to multiple GB. Use Group Policy or wevtutil to cap System log at 512 MB, Application at 256 MB. Large logs increase the chance of block corruption on crash.
Enable file system journaling. Ensure your log drive is NTFS with default journaling. No FAT32 or exFAT — they don't have the transactional integrity needed for log writes.
Install all Windows Server cumulative updates. Microsoft has patched dozens of Event Log bugs since Server 2016. Keep up to date.
Use UPS on critical servers. Unexpected power loss is the #1 cause of partial log block writes. A battery backup buys you time for a graceful shutdown.
Monitor with a health check script. Run wevtutil gl in a scheduled task weekly. If any log shows status Corrupted or Offline, alert before it becomes a problem.