Windows 10/11 Event Logs: Prevent Full-Log Data Loss

Microsoft’s Event Log documentation confirms that the Event Log service supports three practical outcomes at capacity: overwrite the oldest events, retain the existing log and reject incoming events, or retain and automatically back up the full log. Microsoft also documents wevtutil as the supported command-line tool for reading and changing those settings on Windows 10 and Windows 11.

For most standalone PCs and ordinary workstations, a larger circular log is the least risky answer. For servers, incident-response endpoints, or machines governed by an audit-retention requirement, keeping records until they can be exported or collected elsewhere may be appropriate—but only if someone owns the resulting archive files. Retention settings alone do not create a reliable audit trail.

Decide what “retention” needs to accomplish​

Event log capacity is measured in bytes or kilobytes, not days. A 128 MB System log may cover months on an idle desktop, a few days on a busy file server, or far less during a boot loop, driver failure, authentication storm, or malware investigation. The first practical step is to look at the event rate on the actual machine rather than applying the same size everywhere.

The three behaviors available in Event Viewer have very different failure modes:

• Overwrite events as needed makes the log circular. Windows writes new events by replacing the oldest entries once the maximum size is reached. This is normally the right choice for Application and System on unmanaged PCs, provided the log is large enough for the troubleshooting window you need.
• Archive the log when full, do not overwrite events preserves the completed log and starts a new active one. It prevents the old records from being overwritten, but archive files consume local storage until a backup, collection, or cleanup process handles them.
• Do not overwrite events (clear logs manually) keeps the existing records but rejects new entries when the log fills. This should be reserved for a controlled process in which administrators monitor capacity, export the log, and clear it on schedule. It is a poor fit for unattended endpoints.

The consequential mistake is treating “do not overwrite” as a safer version of circular logging. It protects old evidence at the price of losing the newest evidence once the file is full. Microsoft documents Security event ID 1104 as the warning that the Security log has filled under this kind of configuration; it calls for immediate action such as archiving or clearing the log.

Change Application, System, Security, and custom logs in Event Viewer​

Sign in with an administrator account. Press Windows + R, type eventvwr.msc, and press Enter to launch Event Viewer. Expand Windows Logs to find the classic Application, Security, Setup, System, and Forwarded Events logs.

For each log you want to change:

1. Right-click the log, such as System, and select Properties.
2. Record the existing maximum log size and the current retention behavior before changing anything. If the log contains an active incident or evidence you may need later, use Save All Events As first and store the exported .evtx file outside the machine where possible.
3. In Maximum log size (KB), enter a size that fits the device’s event volume and available system-drive capacity. Common starting points might be 64 MB or 128 MB for Application and System on a troubleshooting-focused PC, but the correct number comes from the machine’s history and the period you need to investigate.
4. Under When maximum event log size is reached, select the appropriate behavior.
5. Select Apply and then OK.

For a provider-specific or custom channel, expand Applications and Services Logs, find the applicable channel, right-click it, and select Properties. Many of these channels are disabled, operational, analytic, or debug logs with different event volumes and access rules. Do not bulk-increase every channel simply because it appears in the tree. Identify logs that routinely contain evidence you need—such as Windows Update, DeviceSetupManager, PowerShell, Task Scheduler, Defender, or an application’s own Operational log—and size those deliberately.

The Security log deserves its own decision. It can grow quickly when advanced audit policies record successful logons, object access, process creation, or other high-volume activity. A larger Security log is often sensible, but selecting manual clearing without a monitored export or centralized collection process merely trades overwritten history for a future logging gap.

Use wevtutil when the setting must be repeatable​

Event Viewer is convenient for one machine. wevtutil.exe is more useful when documenting a build standard, checking a remote-management script, or applying the same configuration across a controlled fleet. Run Command Prompt or Windows Terminal as administrator.

Start by inspecting the live configuration:

wevtutil gl Application
wevtutil gl System
wevtutil gl Security

The gl command reports properties including the enabled state, log path, maximum size, retention setting, and auto-backup setting. For more structured output suitable for review or scripting, use:

wevtutil gl System /f:xml

To configure a 128 MB circular System log, use the byte value for 128 MB:

wevtutil sl System /ms:134217728 /rt:false

/rt:false means retention is disabled in the Event Log service’s terminology: incoming events overwrite the oldest records when the log reaches its limit. This corresponds to Event Viewer’s Overwrite events as needed option.

To retain and automatically archive a 256 MB Application log when it becomes full:

wevtutil sl Application /ms:268435456 /rt:true /ab:true

Microsoft’s wevtutil reference makes an important dependency explicit: /ab:true requires /rt:true. Enabling retention without automatic backup is not archival; it preserves the full log and discards incoming events. That setting should be used only when manual export and clearing are a defined, monitored procedure.

A custom channel follows the same pattern, though its name must match exactly what wevtutil el lists. Enumerate available logs first:

wevtutil el

Then inspect and configure a specific channel. Quotes are useful for names containing spaces:

wevtutil gl "Microsoft-Windows-PowerShell/Operational"
wevtutil sl "Microsoft-Windows-PowerShell/Operational" /ms:67108864 /rt:false

Microsoft specifies a minimum log size of 1 MB for wevtutil, and log files are stored in 64 KB increments. Windows rounds entered values as necessary, so verify the resulting configuration with wevtutil gl <LogName> instead of assuming the requested value was applied exactly.

Check whether policy will overwrite the local setting​

A local Event Viewer change is not necessarily the final configuration on a work-managed device. Group Policy and MDM can enforce maximum size and full-log behavior separately for Application, Security, and System. Microsoft’s EventLogService policy documentation identifies these controls under Computer Configuration > Administrative Templates > Windows Components > Event Log Service and supports them on Windows 10 and Windows 11 business editions.

On a domain-joined PC, generate a policy report after making a local change:

gpresult /h C:\Temp\EventLogPolicy.html

Open the resulting report and look for Event Log Service policies affecting Application, System, or Security. If policy is configured, correct the setting in the domain GPO or device-management profile rather than repeatedly changing Event Viewer on individual devices. Local settings will otherwise revert during the next policy refresh.

There is a subtle administrative split here. wevtutil controls an individual log channel directly. Group Policy and MDM express an organizational rule that can apply to many devices. Use the former for investigation and controlled exceptions; use the latter for a documented fleet standard.

Microsoft’s policy guidance also distinguishes the Security log: its managed maximum-size setting supports a minimum of 20 MB, while Application and System can be managed from 1 MB upward. The broader lesson is to validate a final policy-applied value, especially when a script uses a smaller setting that policy later rejects or replaces.

Avoid turning audit retention into an outage​

The most dangerous combination is a Security log configured never to overwrite events alongside the security policy Audit: Shut down system immediately if unable to log security audits. Microsoft warns that, when this shutdown policy is enabled and Windows cannot write a security audit—commonly because the Security log is full—the computer can halt with audit-failure stop code C0000244.

That behavior exists for environments where allowing activity without an audit record is unacceptable. It also creates a denial-of-service risk: a burst of authentication or other auditable activity can fill the log and take the computer offline if capacity, export, and response procedures are inadequate. Do not enable it casually on a workstation or server just because retaining Security events sounds safer.

For Security logs that must remain locally preserved, use a sufficiently large maximum size, automatic archive or centralized collection, storage monitoring, and an explicit retention-and-cleanup process for exported .evtx files. An archived file left indefinitely on the same disk is neither a durable backup nor a useful response plan.

Verify the result and revisit it after a real incident​

After applying changes, reopen the log’s Properties dialog or run wevtutil gl again. Confirm the maximum size, retention state, and auto-backup state rather than relying on a command’s lack of error output. Then inspect free disk space, particularly if automatic archiving is enabled.

Review the configuration after an actual troubleshooting event. If the oldest record remaining in System predates the issue by only a day or two, increase capacity or collect the log elsewhere. If the log holds months of low-value noise while a more useful provider channel wraps every day, resize the specific channel that carries the evidence.

The practical goal is a known investigation window: enough Application and System history to diagnose failures, enough Security history to meet the organization’s audit need, and no full-log setting that silently discards the records you need next—or takes a machine down because nobody planned for the archive.