Fix STATUS_LOG_BLOCK_INCOMPLETE 0XC01A0004 Error

Quick answer: Run chkdsk /f on the drive with the logs, then restart. If that doesn't clear it, delete the log files (if safe) or restore from a backup that worked before the corruption.

You're seeing this error because Windows' log service ran into a block of data that got cut off or scrambled. This happens most often on Windows Server 2016, 2019, or 2022 when you're running a VSS backup (like with Windows Server Backup or a third-party tool) or when Exchange Server or SQL Server is writing transaction logs. The drive itself might have bad sectors, or a sudden power loss, a crash, or an unclean shutdown left a log in a half-written state. You'll usually find this error in the System event log with Event ID 33 or 632, paired with the source being "Ntfs" or "volsnap". Let's get it fixed.

Main Fix: Run chkdsk and Clear the Logs

Open Command Prompt as Administrator. Click Start, type cmd, right-click Command Prompt, and pick "Run as administrator".
Run a disk check on the affected drive. If the error popped for your system drive (usually C:), type this and press Enter:
```
chkdsk C: /f
```
If the drive is in use (it will be for C:), you'll see a message asking if you want to schedule it for next reboot. Type Y and press Enter.
Restart the server. The disk check will run before Windows boots. What you should see: A blue screen with a progress bar showing "Chkdsk is verifying files..." and then "Chkdsk is verifying indexes...", then "Chkdsk is verifying security descriptors...", and finally "Windows has checked the file system and found no problems" or details of fixes applied. Let it finish completely — don't interrupt it.
After the restart, check if the error is gone. Open Event Viewer (eventvwr.msc), go to Windows Logs > System, and look for Event ID 33 or 632 from source "Ntfs" or "volsnap". If you don't see new ones, you're good.
If chkdsk found and fixed bad sectors (it'll say something like "recovered 1 bad cluster"), run a full chkdsk with the bad-sector scan next, but only after hours — it takes a long time:
```
chkdsk C: /r
```
This scans every sector, not just metadata. Expect this to take hours on a large drive.

If chkdsk Didn't Fix It — Clear the Log Files

Sometimes the corruption is in the log files themselves, and chkdsk can't repair them because the drive's metadata is fine. Here's the next step.

Identify which logs are causing the problem. Look at the event details. If the error mentions a specific file path like C:\Windows\System32\winevt\Logs\System.evtx or a database log like E:\Exchange\Logs\E00.log, that's your target.
For system event logs (like System.evtx): You can clear them safely. Open Event Viewer, right-click "System" under Windows Logs, and pick "Clear Log...". A prompt will ask if you want to save it first — click "Clear" without saving. What you should see: The log is now empty and starts collecting new events.
For application logs (like Exchange or SQL): Stop the related service first. For Exchange, run in an admin Command Prompt:
```
net stop MSExchangeIS
```
Then delete the log files from the folder. For Exchange, that's usually C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\Mailbox Database\*.log. Be careful: Only delete logs if you have a recent backup of the database. If you're not sure, skip this and go to the restore step.
Restart the service after deleting:
```
net start MSExchangeIS
```
Check Event Viewer again for the error.

Alternative Fix: Restore from a Known-Good Backup

If you can't clear the logs or the error keeps coming back, the corruption goes deeper. You'll need to restore the affected volume from a backup taken before the corruption started. This is the nuclear option, but it's reliable.

Boot from a Windows Server installation media or a recovery drive.
Use the "System Image Recovery" option to restore the drive from a backup.
Or, if it's a database like Exchange, restore the database from a VSS-aware backup using your backup software.
After the restore, run chkdsk /f on the restored drive to catch any leftover issues.

Prevention Tips

Make sure your UPS is working. A sudden power loss is the #1 cause of partial log blocks. Test your UPS quarterly.
Run chkdsk regularly. Schedule a monthly chkdsk on all drives with logs. I set up a Task Scheduler job that runs chkdsk C: /scan every Sunday at 3 AM — it checks for issues without fixing them, then alerts me via email if it finds anything.
Keep your backup software up to date. Older VSS writers (like in Windows Server 2016 before a certain CU) can create corrupt log blocks. Install the latest cumulative updates.
Monitor Event ID 33 and 632. Set up an alert in your monitoring tool (like SCOM or PRTG) so you know the second a partial log block shows up, before it takes down a backup job.

This error rarely means you're about to lose data — it's usually a warning that a log got half-written. The fixes above handle 95% of cases. If you're still stuck after these steps, your best bet is a full restore. Don't keep running chkdsk over and over — it won't fix a broken log file, only a broken disk.