That error is a pain, I know. You're trying to clear or rotate logs and Windows just refuses, throwing 0X000019D8 at you. Let's cut the chatter and get to the fix.
The Straight Fix: Release the Locked Handle
What's actually happening here is the Event Log service (or a backup agent, or even a misbehaving antivirus) has an open handle to the log file you're trying to delete. The OS won't delete a file that's in use—that's by design. So the first thing you do is restart the service that owns the log.
net stop eventlog
net start eventlog
That clears most transient locks. But if the error persists, the handle is held by something else—often the Volume Shadow Copy service or a third-party backup tool. Restart those too:
net stop vss
net start vss
If you're dealing with a specific log file and you know which service uses it (like IIS or SQL Server), stop that service as well, delete the log, then start it again. The reason step 3 works is you're removing the active reference count on the file. Once the last handle closes, the NTFS file system allows deletion.
Why This Fix Works
The log service's job is to append to files, not to manage their lifecycle. When it tries to delete a file that has an open handle, it gets ERROR_LOG_CANT_DELETE. Restarting the service forces all handles to close, which releases the file. If a shadow copy (VSS snapshot) references the log, that also prevents deletion—that's why stopping VSS helps. You're essentially clearing all references so the file system can do its job.
One more thing: check if the file system itself is having issues. A corrupt MFT entry can make a file undeletable even with no open handles. Run chkdsk /f on the volume—it'll schedule a check on reboot if the drive is in use. That's a blunt tool, but it catches the weird NTFS corruption cases that cause this exact error.
Less Common Variations
1. Corrupt Event Log Registry Keys
Sometimes the log service isn't even reaching the file—it fails earlier because the registry key for that log is corrupted. The error still shows the same code. The fix is to export, then delete, the specific log key under:
HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Find the subkey matching your log name (like Application or System), export it for backup, delete it, then restart the service. The service recreates the key with defaults. This is more invasive, so only do it if you've confirmed it's the problem—look for Event ID 1104 in the System log.
2. File Permission or Ownership Issues
If the log file is on a non-standard path, like a network share or a custom folder, and the service account lost Delete permission, you get this error. Check the file's ACL:
icacls "C:\Windows\System32\winevt\Logs\Application.evtx"Make sure the service account (usually SYSTEM) has full control. If not, take ownership and grant rights:
takeown /f "C:\path\to\log.evtx"
icacls "C:\path\to\log.evtx" /grant SYSTEM:FThis works because the log service runs as SYSTEM, and if SYSTEM can't delete, it won't even try to unlink the file.
3. Antivirus or Backup Software Interference
Real-world trigger: you installed a new endpoint backup agent that holds open handles to log files for continuous replication. It's not obvious because the agent isn't using the same service name. The symptom appears after the agent is installed, returns after you restart the Event Log service. The fix is to exclude the log directory from the agent's monitoring scope, or stop the agent's service temporarily to confirm it's the culprit.
sc query | findstr /i "backup"Look for suspicious services, stop them one by one, and retest deletion. It's tedious but effective.
Prevention: Stop It Before It Starts Again
Most of these issues come from third-party software touching log files without playing nice. Here's how you keep 0X000019D8 from showing up again:
- Configure backup agents to exclude
%SystemRoot%\System32\winevt\Logs. They don't need to back up live event logs—use the built-in export functions instead. - Set log size limits and rotation policies in Event Viewer (
wevtutil sl). If logs auto-archive properly, you'll rarely need to delete files manually. - Keep VSS snapshots in check. If you see this error after a backup, reduce the number of snapshots or move logs to a different volume that isn't shadow-copied.
- Monitor for handle leaks using
handle.exefrom Sysinternals. If you see a process holding an event log handle for days, that's your warning. - Run
sfc /scannowperiodically to catch system file corruption early, before it manifests as weird log service errors.
The real fix is often simpler than you think: release the handle, check the file system, and look at what's touching your logs. Skip the registry hacks until you've tried the obvious. You'll save yourself an afternoon.