Event ID 1102 (or 104 on older systems)

Security Event Log Integrity Compromised – Quick Fix

Cybersecurity & Malware Intermediate 👁 11 views 📅 Jun 19, 2026

When Windows flags your security log as tampered, it's usually an overprotective antivirus or a corrupt log file. Here's how to fix it in minutes.

When This Error Shows Up

You're checking Event Viewer after a security alert, and bam—Event ID 1102 or 104. It says the audit log was cleared or tampered with. This usually happens right after a Windows Update (especially feature updates like 22H2 or 23H2), or after an antivirus scan went rogue. I've seen it most often on Dell and HP business machines running Windows 10 Pro or Windows 11 Pro with third-party AV like McAfee or Norton.

The log entry itself reads something like: "The audit log was cleared" or "The security event log integrity is compromised." That's Windows trying to warn you that someone—or something—messed with the log. But nine times out of ten, it's a false alarm caused by a software conflict, not a real security breach.

What's Actually Happening

Every time Windows writes a security audit event, it stamps it with a hash. That hash is a digital signature that proves nobody changed the log after it was written. If the hash doesn't match when Windows checks—say, because an antivirus program quarantined the log file, or a disk error flipped a bit—the system screams "integrity compromised."

The real cause is almost never a hacker. It's either:

  • Antivirus interference – Some AV suites treat the event log as a threat and try to "clean" it.
  • Corrupted log file – A bad sector or failed write operation during a shutdown or update.
  • Cleared logs by another tool – If you or a script ran wevtutil cl Security or used a third-party log management tool.

Don't panic. The fix is straightforward, and I'll walk you through it step by step.

How to Fix It

I'm going to show you two methods. Method 1 is the safe, easy one that works 95% of the time. Method 2 is for when you're sure it's a real issue—maybe you suspect malware—and you want to reset the log from scratch.

Method 1: Reset the Security Log (Quick & Safe)

  1. Open Event Viewer as admin. Press the Windows key, type Event Viewer, right-click it, and pick Run as administrator. You'll get a UAC prompt—click Yes.
  2. Locate the Security log. On the left pane, expand Windows Logs, then click Security. You'll see a list of events. The clear message (Event ID 1102) might be near the top if it just happened.
  3. Clear the log. Right-click Security (on the left pane) and choose Clear Log.... A dialog pops up saying you can save it first—select Save and Clear only if you want a backup for later review. Otherwise, pick Clear.
  4. Wait for the refresh. After you click Clear, Event Viewer will reload the Security log. You should see a new event at the top: Event ID 1102, saying the log was cleared. That's normal—it's Windows recording your action.
  5. Verify the error is gone. Scroll through the new log—check for any other Event ID 1102 or 104 entries. If you see none, the original integrity error was a one-time glitch. Close Event Viewer.

What you should expect: After clearing, the log starts fresh. The integrity error won't appear again unless the underlying cause—like a misbehaving AV—hits again.

Method 2: Full Reset Using Command Line (When Method 1 Fails)

If the error keeps coming back after clearing the log, or if you can't even open the Security log (it's corrupted), use this approach.

  1. Open Command Prompt as admin. Press the Windows key, type cmd, right-click Command Prompt, and choose Run as administrator. Click Yes at the UAC prompt.
  2. Stop the Windows Event Log service. Type this command and press Enter:
    net stop EventLog
    You'll see a message: "The Windows Event Log service is stopping." Wait until it says "stopped successfully."
  3. Delete the Security log file. Type this and press Enter:
    del %SystemRoot%\System32\winevt\Logs\Security.evtx
    If you get an access denied error, make sure you ran step 1 as admin and step 2 completed. If it still fails, you might have a locked file—restart in Safe Mode and try again (explained at the end).
  4. Start the Event Log service back up. Type:
    net start EventLog
    Wait for "The Windows Event Log service was started successfully."
  5. Verify the log regenerates. Open Event Viewer as admin again. Click Windows Logs > Security. You should see an empty log with just one entry: Event ID 1102 saying the log was cleared (from your action). The integrity error is gone.

What you should expect: After deleting the .evtx file, Windows creates a fresh one automatically when the service starts. This wipes all old security events—so if you need past logs for forensics, back them up first (copy the Security.evtx file to a USB drive before deleting).

Still Seeing the Error? Check These

If the error comes back after either method, you've got a persistent cause. Here's what to look at:

  • Antivirus exceptions. Open your AV settings and add an exception for C:\Windows\System32\winevt\Logs\ folder. On McAfee, look for "On-Access Scan" exclusions. On Norton, it's under "Settings > Antivirus > Exclusions/Low Risks." Also add %SystemRoot%\System32\winevt\ (the whole EventLog folder). If you're on Defender, it should be fine—but check Windows Security > Virus & threat protection > Manage settings > Exclusions.
  • Corrupt system files. Run an SFC scan. Open Command Prompt as admin and type:
    sfc /scannow
    Let it finish. It'll replace corrupted system files. Then reboot and check Event Viewer again.
  • Faulty disk. If you're getting disk-related errors in System log (like Event ID 7 or 51), the event log file might be on a bad sector. Run chkdsk C: /f from an admin command prompt. Agree to schedule it at next reboot, then restart.
  • Malware. Rare, but possible. If the integrity error is accompanied by Event ID 1102 appearing randomly (you didn't clear the log), and you see logs about unknown processes creating services, run a full offline scan with Defender or Malwarebytes. Boot from a rescue disk if needed.

The bottom line: For 9 out of 10 people, Method 1 clears the error and it never comes back. If you're the 1 in 10, the antivirus exception or the SFC scan usually nails it.

Was this solution helpful?