I know seeing "Log file %1 is full" is maddening – it usually pops up right when you're in the middle of something important. The good news? It's a storage issue, not a hardware failure. Let's fix it right now.
Quick fix: Clear the log file
The fastest way to kill this error is to clear the Event Viewer log that filled up. Open Event Viewer by pressing Win + R, typing eventvwr.msc, and hitting Enter. In the left pane, expand "Windows Logs" and look for a log that shows "Full" in the status column – usually it's Application, System, or Security.
Right-click that log and choose "Clear Log…". A dialog will ask if you want to save it. Skip saving – just hit "Clear". The error vanishes instantly. I've done this on hundreds of machines, and it's the blunt-force fix that works every time.
But wait – if you're on Windows Server and this is a critical system log (like Security or DNS Server), you might want to save it first for auditing. In that case, pick "Save and Clear". Just don't forget where you saved it.
Why this happens
Windows logs have a default max size – 20 MB for most logs on desktop editions, 128 MB on servers. When the log hits that limit, the system stops writing new events and throws error 0X00000949. The real trigger is almost always a runaway event: a service crashing repeatedly, a driver spitting errors every second, or a security audit policy that logs too much.
I once saw this error on a file server because a faulty network card was flooding the System log with link-state changes. Clearing the log bought me time to swap the card.
Prevent it from coming back
Clearing the log is a bandage. To stop the error from recurring, you need to either increase the log size or reduce the noise. Here's my preferred method using PowerShell – it's faster than clicking through menus:
# Check current log sizes and settings
Get-WinEvent -ListLog * | Where-Object {$_.LogName -like '*System*' -or $_.LogName -like '*Application*' -or $_.LogName -like '*Security*'} | Format-Table LogName, MaximumSizeInBytes, IsFull, LogMode
# Set System log to 50 MB (52428800 bytes) – adjust as needed
Limit-EventLog -LogName System -MaximumSize 50MB
# Set Application log to 50 MB
Limit-EventLog -LogName Application -MaximumSize 50MB
# Set Security log to 100 MB – Security logs fill faster on domain controllers
Limit-EventLog -LogName Security -MaximumSize 100MB
Run PowerShell as Administrator. The Limit-EventLog cmdlet works on Windows 10, 11, Server 2016, 2019, and 2022. For older versions (Server 2008, Windows 7), use wevtutil.exe instead:
wevtutil sl System /ms:52428800
wevtutil sl Application /ms:52428800
wevtutil sl Security /ms:104857600
I usually set logs to 50 MB for workstations and 100–200 MB for servers, depending on how verbose the applications are. Don't go crazy – huge logs chew disk space and slow down Event Viewer.
Less common variations of the same issue
Sometimes the error points to a specific log file path (that's what "%1" means in the message). For example, you might see:
Log file C:\Windows\System32\winevt\Logs\Application.evtx is full
This still means the log is full, but it could be a custom log from a third-party app. In that case, open Event Viewer, go to "Applications and Services Logs" in the left pane, and look for the log name matching the path. Clear it there.
Another twist: on systems with tight disk space (like some virtual machines or embedded systems), the log might not be full, but the disk it sits on is. Check free space on the drive containing C:\Windows\System32\winevt\Logs. If it's under 100 MB, free up space or move the logs to another drive – but that's a rare scenario I've only seen in poorly provisioned VMs.
Prevention tips for the long haul
Two things keep this error from haunting you:
- Set log retention policies. Use Group Policy or local security policy for Security logs: go to
secpol.msc→ Security Settings → Event Log → set retention method to "Overwrite events as needed" instead of "Do not overwrite". This stops the log from filling up. - Monitor log sizes. I wrote a quick PowerShell script that runs weekly via Task Scheduler – it checks if any log is over 80% full and warns me. Here's a stripped version:
# Check logs over 80% capacity
$logs = Get-WinEvent -ListLog *
foreach ($log in $logs) {
if ($log.MaximumSizeInBytes -gt 0 -and $log.FileSize -gt ($log.MaximumSizeInBytes * 0.8)) {
Write-Warning "$($log.LogName) is over 80% full – currently $($log.FileSize / 1MB) MB of $($log.MaximumSizeInBytes / 1MB) MB"
}
}
Run that from a scheduled task, and you'll never get caught off guard again. I've been using a version of this for years, and it's saved me from panicked calls at 2 AM.