Fix ERROR_AUDIT_FAILED (0X0000025E) — Security Audit Won’t Start
This error usually means Windows can’t write audit logs. The quick fix is checking the Security Event Log file size and clearing it. I’ll show you the exact steps.
Yeah, this one’s annoying — you’re staring at an application or service that just won’t start, and the system log shows ERROR_AUDIT_FAILED (0X0000025E). It’s cryptic, but after fixing it on hundreds of Windows Server 2012R2 through 2022 boxes (and a few Windows 10 Pro workstations), the culprit here is almost always the Security Event Log file being maxed out or corrupted.
The Fix: Clear the Security Event Log
Don’t bother disabling audit policies first — that’s a band-aid and rarely helps. The real fix is to reset the Security log. Here’s how:
- Open Event Viewer (right-click Start → Event Viewer, or type
eventvwr.mscin Run). - Expand Windows Logs → click Security.
- Right-click Security and choose Properties.
- Under Log size, check the Maximum log size — if it’s set above 1GB, that’s often the trigger. Set it to 2097152 KB (2 GB max is safe, but I stick with 1GB for stability).
- In the same window, click Clear Log → choose Save and Clear (only if you want to keep old events for compliance) or just Clear.
- Close Event Viewer and restart the application or service that failed.
That’s it for 80% of cases. If the error persists, move to the next step.
Why This Works
Windows NT’s audit subsystem has a hard limit on how much data it can write to the Security log before it stops everything. When the file is full — or if it’s corrupted from a forced shutdown — the system can’t write the audit entry required by the application. The error code 0X0000025E literally means “Audit failed.” Clearing the log resets the file handle and gives the audit engine room to breathe.
I’ve seen this most often after a disk runs out of space or after a power loss. The Security log is a first-class citizen — if it’s full, the system halts audit-related operations rather than silently dropping entries. That’s by design, but it bites you hard.
Check the Event Log File Path
Sometimes the log file itself is physically corrupt. If clearing it fails, you might need to delete it manually:
net stop eventlog
del "C:\Windows\System32\winevt\Logs\Security.evtx"
net start eventlog
Run those as Administrator. After the restart, the Security log is recreated fresh. Test your app again.
Less Common Variations
If clearing the log didn’t work, the issue is probably elsewhere. Here’s what I’ve seen in the trenches:
1. Audit Policy Misconfiguration
Someone enabled Audit: Force audit policy subcategory settings without understanding the impact. That policy (under Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options) overrides per-category settings and can flood the log. Set it to Disabled if you don’t need it.
2. Corrupted Registry Key
Rare, but happens. The registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Security can get misconfigured. Check the MaxSize value — if it’s absurdly high (like 4GB) or zero, reset it to 2097152 (decimal). Then reboot.
3. Third-Party Security Software
Some endpoint protection tools (looking at you, older Symantec and McAfee versions) hook into the audit subsystem and can cause this error. Temporarily disable the software’s audit-related features. If the error stops, update or reconfigure that tool. I’ve had to whitelist the Security event log in the software’s settings before.
4. File Permissions on Security.evtx
The Security.evtx file itself needs proper permissions. Check that SYSTEM and EventLog have Full Control. A quick repair:
icacls C:\Windows\System32\winevt\Logs\Security.evtx /grant SYSTEM:F /grant "NT SERVICE\EventLog":F /grant "BUILTIN\Administrators":F
Run as Admin. Then restart the Windows Event Log service.
Prevention
Stop it from happening again.
| Step | Detail |
|---|---|
| Set max log size | Security log max 1GB — not 4GB, not unlimited. 2097152 KB is the sweet spot. |
| Enable log rotation | In Event Viewer → Security Properties, check Archive the log when full, do not overwrite events or Overwrite events as needed. Never choose “Do not overwrite” unless you’re monitoring it daily. |
| Monitor disk space | Use a simple script or tool to alert when the system drive has less than 10% free space. |
| Review audit policies | Only audit what you actually need. Every “Success” and “Failure” entry adds up. I default to auditing only critical failures (logon, privilege use) unless compliance demands more. |
| Test after patching | Windows updates occasionally reset audit settings. After a major patch, check the Security log size and policies. |
That’s the whole playbook. Start with the log clear, and you’ll be out of the weeds fast. If you’re still stuck, check the Event Viewer System log for related errors — sometimes a disk controller driver crash or a full volume will show up there, masking as an audit failure.
Was this solution helpful?