STOP 0xC01A0013: Log read/write past start of log — fixed

This error is a pain, but you don't need to rebuild the server

I've seen 0xC01A0013 pop up on everything from Windows Server 2016 to Azure VM instances. It's that moment when the log service tries to read or write past the start of the log — basically, the log file is corrupted or truncated. Last month, a client's print server threw this after a failed disk mirror rebuild. Here's how I fixed it in under 20 minutes.

The real fix: reset or delete the log file

You've got two options. I always try the first one first — it's less destructive.

1. Find which log file is the problem.
   Check the System event log for Event ID 0xC01A0013. It'll usually point to a specific .edb or .log file. Common culprits are the Windows Event Log (.evtx) files or the Active Directory database log (if this is a DC).
2. Stop the service tied to that log.
   For Event Log, run net stop EventLog in an elevated command prompt. For AD logs, stop the NTDS service.
3. Rename or delete the offending log file.
   Go to the path from the error (e.g., C:\Windows\System32\winevt\Logs\System.evtx). Rename it to something like System.old. Don't delete — keep a copy for 24 hours in case something goes sideways.
4. Restart the service.
   Run net start EventLog. The service will create a fresh, clean log file automatically.
5. Reboot the server.
   Not strictly needed, but I do it to flush any lingering handles.

If the error is tied to a database like Exchange or AD, use esentutl /r to recover the log first before deleting.

Why this works

0xC01A0013 means the log service has hit a pointer that's pointing to a location before the start of the file — like reading page 0 in a book that starts at page 5. This usually happens after a crash, an improper shutdown, or a disk block goes bad. By deleting the corrupted log, you let the service build a new one from scratch. The service is smart enough to start fresh — it doesn't need the old log unless you're mid-transaction.

I had a client last month whose entire print queue died because of this — the spooler service log got corrupted after a power outage. Same fix: delete the spooler's .log file, restart, and it was back in business.

Less common variations you might hit

The file isn't deletable

Sometimes the log file is locked, even after stopping the service. In that case, boot into Safe Mode and delete it from there. Or use a tool like Unlocker. I've also had to use takeown /f filename followed by icacls filename /grant administrators:F to force delete permissions.

Error keeps coming back after fix

If the error reappears shortly after, you've got a disk issue. Run chkdsk /f /r on the drive holding the logs. Last year, a client's Hyper-V host kept throwing 0xC01A0013 on the VM logs — turned out the NVMe SSD had bad blocks. A disk replace fixed it permanently.

The log is in use by a database engine

This is common with Exchange or SQL Server. You can't just delete those logs. Instead, run a full backup of the database (which truncates the logs automatically), or use esentutl /g to verify the log. If it's toast, esentutl /p can recover the database — but I've had mixed results with recovery. I always take a full backup first.

It's the Event Log itself

For Windows Event Log specifically, you can clear it via the Event Viewer GUI under "Clear Log..." — which is the same as deleting but fancier. Or use PowerShell: Clear-EventLog -LogName System. Same effect, less hassle.

How to prevent it from coming back

This error is almost always caused by an improper shutdown or disk corruption. Three things I tell every client:

• Use a UPS. A clean power shutdown prevents the log from getting truncated mid-write. Cheap UPS, saves expensive headaches.
• Monitor disk health. Run SMART checks monthly. I use a free tool called CrystalDiskInfo on smaller servers. If reallocated sectors go up, replace the disk.
• Set log file size limits. If a log grows uncontrolled and hits a full disk, corruption can result. In Event Viewer, set a maximum log size (like 20MB for System logs) and enable overwrite as needed.

"The quickest fix is often the simplest. Don't overthink a corrupted log — just replace it."