| Previous | Next |
| ERROR_BAD_COMPRESSION_BUFFER | ERROR_TIMER_RESOLUTION_NOT_SET |
ERROR_AUDIT_FAILED
What ERROR_AUDIT_FAILED means
The code concerns the auditing path, not merely the business operation being audited. Depending on security policy, failure to record an audit can cause the original operation to fail because allowing it without an audit trail would violate policy.
Where it commonly appears
- Security-sensitive logon and authorization paths
- Services generating mandatory object-access audits
- Systems with strict audit-failure policy
- Security event-log or LSA failures
Likely causes
- The security event log or audit subsystem is unavailable
- Audit storage is full or cannot be written
- A required audit parameter is invalid
- Policy requires auditing but the caller cannot complete it
- A security service is shutting down or unhealthy
Diagnostic checklist
- Check the Security and System logs for audit-service and event-log failures
- Verify event-log capacity, retention policy, and disk free space
- Identify whether the operation succeeds when the relevant audit policy is not mandatory in a controlled test
- Record the privilege set, object, operation, and policy category involved
- Check for service restarts or policy refresh at the same time
Guidance for developers
Do not bypass mandatory auditing or silently downgrade the operation. Return the failure to the caller and preserve the security context. Avoid recursive logging paths where reporting the audit failure itself requires the same unavailable audit channel.
Guidance for administrators
Restore the event-log and security services, free or archive log space according to policy, and verify audit configuration. Changes to audit policy should follow organizational security controls rather than being used as an ad hoc workaround.
Example incident
A privileged configuration change requires a success audit, but the Security log cannot accept new records. Windows rejects the change with this code. Expanding or repairing the log restores the operation while preserving the audit requirement.
Related conditions
This is not equivalent to ERROR_ACCESS_DENIED. Authorization may have succeeded; the operation failed because the required audit record could not be completed.
Operational decision points
The first production question is whether this event reflects a mandatory auditing condition and not merely a transient API failure. For ERROR_AUDIT_FAILED, the deciding evidence is audit category, security context, event-log health, retention mode, disk state. Preserving this first-occurrence evidence is more useful than increasing retry frequency for investigation sequence 1.
- Impact boundary: identify the exact process, account, device, file, session, host, or connection affected by this result; do not assume the whole machine is in the same state.
- State change required: the next attempt is justified only after the relevant mandatory auditing state can differ from the failed attempt.
- Partial outcome: verify whether the operation allocated resources, changed data, sent a request, or modified policy before this result was returned.
- Escalation evidence: preserve audit category, security context, event-log health, retention mode, disk state together with component version and the first preceding failure.
Concrete recovery example
Consider a case where a privileged change required an audit while the Security log could not accept records. Repeating the same call leaves the underlying condition unchanged and produces another this result. The durable response is to restore the audit channel without bypassing policy. Validation for it should use one controlled operation and inspect both the returned status and the resulting state associated with case 1.
Monitoring and validation
A monitoring rule for it should distinguish first occurrence from repetition, group events by affected object, and correlate them with deployments or configuration changes. The recovery is complete only when the expected mandatory auditing state is present and consistent; absence of another log line by itself is not sufficient proof.
Retain the original this result event until validation for investigation case 1 is complete. After it is corrected, verify that no partial or stale artifact specific to remediation sequence 1 remains before declaring recovery complete. This it-specific verification prevents a hidden secondary problem from surviving after remediation step 1.
References
Looking for a different code? Search another status or error code.