What is the difference between Event ID 1116 and Event ID 1117?

Event 1116 fires when Windows Defender detects a threat — it records what was found (threat name, file path, detection source). Event 1117 fires when Defender takes an action on that threat — it records what was done (quarantine, remove, block, or allow). Think of 1116 as the detection alert and 1117 as the remediation outcome. In a successful automated response, you see a 1116 followed immediately by a 1117 with Action Type = Quarantine. The dangerous scenario is a 1116 with no 1117, or a 1117 with Action Type = 'No Action Taken' or 'Allowed by User' — meaning the threat ran without interference.

Is Event ID 1117 always a sign that the threat was removed?

No. The Action Type field in 1117 determines the outcome. 'Quarantine' and 'Remove' mean the threat was contained — the file was moved to the Defender quarantine store or deleted. 'Block' means execution was prevented. 'No Action' or 'Allowed' mean the threat was detected but not stopped — it may have executed. 'Allowed by User' means someone explicitly allowed the threat to run, which warrants investigation. Always check the Action Type before concluding the threat is contained. If Action = 'Allowed', treat the machine as compromised until proven otherwise.

Why would Event ID 1117 show 'No Action Taken' even though Defender detected the threat?

Several scenarios cause this: (1) The file is in a Defender exclusion path — Defender detected it but exclusion policy prevented action; audit your exclusion list for paths that should not be excluded. (2) Real-time protection was disabled at detection time — check Event 5001 (Defender real-time protection disabled) before the 1117. (3) The threat was classified as a Potentially Unwanted Application (PUA) and PUA protection is not enabled in your policy. (4) A tamper protection race condition — the malware executed and was partially quarantined but had already written additional files. In all cases, treat 'No Action Taken' as an active incident.

How do I know if the threat was fully remediated after Event ID 1117?

Event 1117 alone does not guarantee full remediation — it only records what Defender acted on at the time of detection. Verify full remediation by: (1) checking that no 1116 events fire for the same threat name in the following 24 hours (re-detection = re-infection or persistence mechanism survived); (2) reviewing Event 4688 for processes the malware may have spawned before detection (child processes, persistence installers); (3) checking for new scheduled tasks (4698), services (7045), or registry run keys (4657) created around the 1116 timestamp; (4) running a full Defender scan and checking Event 1001 (scan completed) for additional detections. If any persistence mechanism survived, the threat can re-establish itself after quarantine.

Scan your Security and Sysmon logs·Detection guides

Event ID 1117InformationMicrosoft-Windows-Windows Defender/Operational

Windows Event ID 1117 — Windows Defender — Malware Remediation Action

Logged when Windows Defender takes a remediation action on a detected threat — quarantine, removal, block, or allow. Always follows Event ID 1116 (threat detected). The action outcome determines whether containment succeeded or the threat is still active.

Why It Matters

1117 answers the question 1116 leaves open: did Defender actually stop the threat? A Quarantine Succeeded means the malicious file is isolated. A Failed remediation means the malware protected itself — common with rootkits, ransomware mid-encryption, or threats that hook system processes to block deletion. 'Allowed by User' is the most concerning outcome: a user clicked Allow on the Defender prompt, overriding detection and permitting the threat to execute fully. This frequently happens when employees dismiss warnings on targeted phishing attachments or cracked software. Even a Quarantine Succeeded does not mean the threat didn't already execute — Defender detects on write or execution attempt, so process activity, network connections, and registry changes may have already occurred in the window between execution and detection.

Key Fields

Threat NameThe malware family or signature name — use this to research the threat's behavior, typical C2 infrastructure, and persistence mechanisms. Cross-reference with VirusTotal or Microsoft Threat Intelligence.

Action NameWhat Defender tried to do: Quarantine (isolate the file), Remove (delete), Block (prevent execution), or Allow (user overrode — treat as no remediation). 'Quarantine Failed' = malware resisted removal.

Action StatusSucceeded or Failed — Failed requires manual intervention. Combine with Action Name: 'Quarantine Failed' is the most dangerous combination, indicating active malware that prevented its own removal.

PathThe file path of the remediated threat — location reveals persistence mechanism: AppData = user-installed, Temp = dropper, System32 = driver/rootkit, Startup folder = run-key persistence.

Process NameThe process that triggered the detection — if it was Word, Excel, or Outlook, you have a document-based delivery (macro or exploit). If it was a browser, likely a drive-by or malicious download.

Investigation Tips

1.'Allowed by User' is an incident: the user clicked Allow on a Defender security warning, permitting the threat to execute unchecked. Identify who approved it, what process ran, and what it did in the minutes after. This is the most common reason Defender-detected threats become full compromises.
2.Failed remediations indicate active resistance: malware that blocks its own removal has typically already established persistence (service, driver, run key, scheduled task) or is actively encrypting files. Escalate immediately to endpoint isolation and manual forensic investigation.
3.Successful quarantine ≠ safe: determine exactly when the threat first appeared on the system vs. when it was detected. The gap between first execution and detection is the window of activity. Check 4688 (process creation), 5140 (network share access), and DNS logs for that window.
4.Correlate Process Name with the delivery vector: Office applications spawning unexpected child processes before 1116/1117 = macro-based delivery. Browser processes = drive-by download. LSASS or svchost = memory injection or living-off-the-land.
5.Cross-host spread: if the same Threat Name appears in 1117 events across multiple endpoints within a short window, you have active lateral spread — likely via network shares (5140), admin shares, or domain-wide script execution.

Detection Logic

Microsoft Sentinel (KQL) — surface failed or user-overridden Defender remediations, which indicate active or partially-contained threats.

// Defender remediations that failed or were overridden by the user
Event
| where Source == "Microsoft-Windows-Windows Defender"
| where EventID == 1117
| extend ActionName = extract(@"Action Name:s*(.+?)[
]", 1, RenderedDescription)
| extend ThreatName = extract(@"Threat Name:s*(.+?)[
]", 1, RenderedDescription)
| extend ActionStatus = extract(@"Action Status:s*(.+?)[
]", 1, RenderedDescription)
| where ActionName has_any ("Allow", "fail", "Fail")
    or ActionStatus has_any ("fail", "Fail")
| project TimeGenerated, Computer, ThreatName, ActionName, ActionStatus
| sort by TimeGenerated desc

// Pair with 1116 (detection) to get full picture
Event
| where Source == "Microsoft-Windows-Windows Defender"
| where EventID in (1116, 1117)
| extend ThreatName = extract(@"Threat Name:s*(.+?)[
]", 1, RenderedDescription)
| summarize DetectionCount=countif(EventID==1116),
    RemediationCount=countif(EventID==1117)
    by ThreatName, Computer, bin(TimeGenerated, 1h)
| where DetectionCount > 0

Seeing Event ID 1117 in your own logs? Upload an .evtx file — EventPeeker flags windows defender — malware remediation action automatically, maps it to MITRE ATT&CK, and writes the triage report. No account, files auto-deleted.

Analyze my logs →

Related Event IDs

1116Defender threat detected — the preceding detection event; always investigate 1116 and 1117 together

4688Process creation — what ran before and after the Defender action

4657Registry value modified — malware often sets persistence keys before Defender acts

7045New service installed — some malware installs a service before Defender quarantines the dropper

Frequently Asked Questions

What is the difference between Event ID 1116 and Event ID 1117?: Event 1116 fires when Windows Defender detects a threat — it records what was found (threat name, file path, detection source). Event 1117 fires when Defender takes an action on that threat — it records what was done (quarantine, remove, block, or allow). Think of 1116 as the detection alert and 1117 as the remediation outcome. In a successful automated response, you see a 1116 followed immediately by a 1117 with Action Type = Quarantine. The dangerous scenario is a 1116 with no 1117, or a 1117 with Action Type = 'No Action Taken' or 'Allowed by User' — meaning the threat ran without interference.
Is Event ID 1117 always a sign that the threat was removed?: No. The Action Type field in 1117 determines the outcome. 'Quarantine' and 'Remove' mean the threat was contained — the file was moved to the Defender quarantine store or deleted. 'Block' means execution was prevented. 'No Action' or 'Allowed' mean the threat was detected but not stopped — it may have executed. 'Allowed by User' means someone explicitly allowed the threat to run, which warrants investigation. Always check the Action Type before concluding the threat is contained. If Action = 'Allowed', treat the machine as compromised until proven otherwise.
Why would Event ID 1117 show 'No Action Taken' even though Defender detected the threat?: Several scenarios cause this: (1) The file is in a Defender exclusion path — Defender detected it but exclusion policy prevented action; audit your exclusion list for paths that should not be excluded. (2) Real-time protection was disabled at detection time — check Event 5001 (Defender real-time protection disabled) before the 1117. (3) The threat was classified as a Potentially Unwanted Application (PUA) and PUA protection is not enabled in your policy. (4) A tamper protection race condition — the malware executed and was partially quarantined but had already written additional files. In all cases, treat 'No Action Taken' as an active incident.
How do I know if the threat was fully remediated after Event ID 1117?: Event 1117 alone does not guarantee full remediation — it only records what Defender acted on at the time of detection. Verify full remediation by: (1) checking that no 1116 events fire for the same threat name in the following 24 hours (re-detection = re-infection or persistence mechanism survived); (2) reviewing Event 4688 for processes the malware may have spawned before detection (child processes, persistence installers); (3) checking for new scheduled tasks (4698), services (7045), or registry run keys (4657) created around the 1116 timestamp; (4) running a full Defender scan and checking Event 1001 (scan completed) for additional detections. If any persistence mechanism survived, the threat can re-establish itself after quarantine.

Go deeper: the full detection guide

Builds on this page with the attack chain, step-by-step investigation, immediate containment actions, KQL/Sigma detection queries, and an annotated example log.

View the full guide for Event ID 1117 →

See Event ID 1117 in your logs

Upload a Windows Event Log (.evtx) file — EventPeeker automatically detects windows defender — malware remediation action patterns, maps findings to MITRE ATT&CK, and generates an AI triage report.

Analyze EVTX Logs Free →

← All detection guides·Analyze EVTX Logs Free →