Event IDs 10001/4010: Poison Queue - Fix Guide 2025
Complete troubleshooting guide for Exchange Server Event IDs 10001 and 4010 poison queue errors. Learn how to identify problematic messages, clear the poison queue, and restore normal mail flow in 15-30 minutes.
Table of Contents
Event IDs 10001 and 4010 indicate Exchange has detected a "poison message" - an email that repeatedly crashes the Transport service during processing. Exchange quarantines these messages to protect mail flow, but understanding why messages become poisoned is crucial for preventing recurrence.
Our Exchange Mail Flow Recovery Team regularly investigates poison message scenarios. This guide shows you how to safely handle poisoned messages and restore normal operations.
Error Overview: What Poison Queue Events Mean
Exchange Transport implements a crash detection mechanism. When processing a specific message causes the service to crash three times, that message is moved to the special "Poison" queue to prevent further disruption.
Log Name: Application
Source: MSExchangeTransport
Event ID: 10001
Level: Warning
Description: Message with ID <message-id@domain.com> has been
moved to the poison message queue because it caused
the transport service to crash.
Log Name: Application
Source: MSExchangeTransport
Event ID: 4010
Level: Error
Description: The transport service encountered a message that
caused an unexpected exception. The message has
been quarantined.The poison detection process:
Poison Message Detection Flow
Symptoms & Business Impact
What Users Experience:
- Brief email delays during service restarts
- One specific email never delivers (the poison message)
- Sender may receive delayed NDR if poison message expires
- Generally mail flow resumes quickly after quarantine
What Admins See:
- Event IDs 10001, 4010 in Application log
- MSExchangeTransport service restart events
- Poison queue in Queue Viewer with messages
- Watson crash reports if debugging enabled
- Brief periods of mail flow interruption
Business Impact:
- Single Message Loss: Poison message may not deliver
- Intermittent Delays: Service restarts cause brief queuing
- Potential Pattern: If source keeps sending similar messages, repeated issues
- Investigation Time: Admin effort to identify root cause
Common Causes of Poison Messages
1. Malformed Message Headers (40% of cases)
Messages with invalid RFC 5322 headers, extremely long header lines, or unusual character encodings can crash the header parser.
Common patterns: Invalid Date headers, malformed Message-ID, binary content in text headers
2. Transport Agent Bugs (25% of cases)
Third-party transport agents (antivirus, DLP, archiving) may have bugs triggered by specific message content or structure.
Identified by: Crash dump shows third-party DLL in stack trace
3. Oversized or Nested Attachments (15% of cases)
Deeply nested MIME structures, extremely large single attachments, or thousands of small attachments can exhaust parser resources.
Identified by: Poison message has unusual attachment structure
4. Exchange Software Bug (12% of cases)
Bugs in Exchange's own categorizer, routing engine, or content conversion can be triggered by edge-case messages.
Identified by: Crash dump shows Microsoft Exchange DLLs; often fixed in CU updates
5. Malicious Messages (8% of cases)
Deliberately crafted exploit attempts or malformed spam designed to crash mail servers.
Identified by: Message from unknown sender, suspicious source
Quick Diagnosis: Investigate Poison Messages
📌 Version Compatibility: This guide applies to Exchange 2016, Exchange 2019, Exchange 2022. Commands may differ for other versions.
Run these commands in Exchange Management Shell to analyze poison messages:
# List all queues including Poison
Get-Queue | Select-Object Identity, Status, MessageCount
# View poison queue specifically
Get-Queue -Identity "Poison" | Format-List *
# Get messages in poison queue
Get-Message -Queue "Poison" |
Select-Object Identity, DateReceived, FromAddress, Subject, Status, LastError |
Format-Table -AutoSizeWhat to look for:
- Number of messages in Poison queue
- Sender addresses - pattern of same source?
- DateReceived - when did issues start?
- Subject lines - any common themes?
# Get detailed message properties
$poisonMessage = Get-Message -Queue "Poison" | Select-Object -First 1
$poisonMessage | Format-List *
# View message headers (key for diagnosis)
$poisonMessage | Get-MessageHeaders
# Check message size
$poisonMessage | Select-Object Identity,
@{Name="SizeKB";Expression={[math]::Round($_.Size/1KB,2)}}Pro Tip: Export the poison message to a file for detailed analysis. You can open the .eml file in a text editor to examine headers and structure without risking another crash.
# Export poison message to file
$message = Get-Message -Queue "Poison" | Select-Object -First 1
$exportPath = "C:\Temp\PoisonMessage_$(Get-Date -Format 'yyyyMMdd_HHmmss').eml"-Format 'yyyyMMdd_HHmmss').eml"
# Use Export-Message cmdlet
$message | Export-Message -Path $exportPath
# Or via queue database directly
Get-Queue "Poison" | Get-Message | ForEach-Object {
$_.ExportToFile("C:\Temp\Poison_$($_.Identity.ToString().Replace('\','_')).eml")
}# Get Transport crash events
Get-EventLog -LogName Application -Source MSExchangeTransport -Newest 50 |
Where-Object {$_.EventID -in @(10001, 4010, 1000, 1026)} |
Format-Table TimeGenerated, EventID, Message -AutoSize -Wrap
# Check for Watson reports
Get-ChildItem "C:\ProgramData\Microsoft\Windows\WER\ReportQueue" -Recurse |
Where-Object {$_.Name -like "*Exchange*" -or $_.Name -like "*EdgeTransport*"}# List enabled transport agents
Get-TransportAgent | Where-Object {$_.Enabled -eq $true} |
Select-Object Identity, Enabled, Priority
# Check if crashes correlate with specific agent
# Look at crash dump stack trace if available
# Common problematic agents: antivirus, DLP, journalingQuick Fix (10 Minutes) - Clear Poison Queue
Option A: Delete Poison Messages (If Spam/Malicious)
# View messages before deletion
Get-Message -Queue "Poison" |
Select-Object Identity, FromAddress, Subject | Format-Table
# Delete specific message
Remove-Message -Identity "ServerName\Poison\123456" -Confirm:$false
# Delete ALL messages in poison queue
Get-Message -Queue "Poison" | Remove-Message -Confirm:$false
# Verify queue is empty
Get-Queue -Identity "Poison"Option B: Resume Poison Messages (If Fixed)
If you've identified and fixed the root cause (updated transport agent, applied Exchange patch), you can attempt to resume the messages:
# Resume specific message for retry
Resume-Message -Identity "ServerName\Poison\123456"
# Resume all poison messages
Get-Message -Queue "Poison" | Resume-Message
# Monitor if they process successfully
Get-Queue | Select-Object Identity, Status, MessageCount
# If messages become poisoned again, the fix didn't work
Get-Queue -Identity "Poison"Option C: Export and Redeliver Manually
# Export all poison messages
$exportFolder = "C:\Temp\PoisonExport_$(Get-Date -Format 'yyyyMMdd')"-Format 'yyyyMMdd')"
New-Item -ItemType Directory -Path $exportFolder -Force
Get-Message -Queue "Poison" | ForEach-Object {
$fileName = "$($_.FromAddress)_$(Get-Date $_.DateReceived -Format 'HHmmss').eml"Get-Date $_.DateReceived -Format 'HHmmss').eml"
$filePath = Join-Path $exportFolder $fileName
# Export logic depends on Exchange version
}
# After export, delete from queue
Get-Message -Queue "Poison" | Remove-Message -Confirm:$false
# Manually review exported messages
# Redeliver valid ones via SMTP relay or other methodDetailed Solution: Prevent Recurrence
Scenario 1: Transport Agent Causing Crashes
# Disable all third-party agents temporarily
Get-TransportAgent | Where-Object {$_.Identity -notlike "Microsoft*"} |
ForEach-Object { Disable-TransportAgent $_.Identity -Confirm:$false }
# Restart Transport
Restart-Service MSExchangeTransport
# Resume poison messages and see if they process
Get-Message -Queue "Poison" | Resume-Message
# If successful, re-enable agents one at a time
Enable-TransportAgent "Agent Name"
Restart-Service MSExchangeTransport
# Test with poison-prone message again
# The agent that causes re-poisoning is the culprit
# Contact agent vendor for fix or configure agent to skip problematic contentScenario 2: Exchange Bug - Apply Updates
# Check current Exchange version
Get-ExchangeServer | Select-Object Name, AdminDisplayVersion
# Check for available updates
# Visit: https://docs.microsoft.com/exchange/new-features/build-numbers-and-release-dates-numbers-and-release-dates
# After applying CU/SU, test poison messages
Restart-Service MSExchangeTransport
Get-Message -Queue "Poison" | Resume-Message
# Verify processing succeeds
Get-Queue -Identity "Poison"Scenario 3: Block Problem Sender
# If poison messages come from specific sender/domain
# Create transport rule to reject
New-TransportRule -Name "Block Poison Sender" `
-FromAddressContainsWords "badactor@malicious.com" `
-RejectMessageReasonText "Message blocked by policy" `
-RejectMessageEnhancedStatusCode "5.7.1"7.1"
# Or block at connector level
$connector = Get-ReceiveConnector "Default Frontend*"
# Add IP to block list if identifiable
# For pattern-based blocking
New-TransportRule -Name "Block Malformed Messages" `
-HeaderContainsMessageHeader "X-Malformed-Header"-Header" `
-HeaderContainsWords "malformed-pattern" `
-RejectMessageEnhancedStatusCode "5.7.1"7.1"Scenario 4: Adjust Poison Threshold
Pro Tip: Increasing the poison threshold (default 3 crashes) gives more retries but risks more service disruption. Only increase if you're actively debugging and have redundant mail flow.
# Poison threshold is in EdgeTransport.exe.config
# Default: PoisonMessageDetectionEnabled = true
# Default: PoisonThreshold = 3
# Edit: C:\Program Files\Microsoft\Exchange Server\V15\Bin\EdgeTransport.exe.config
# Add or modify in appSettings:
# <add key="PoisonThreshold" value="5" />"5" />
# To temporarily disable poison detection (NOT recommended for production)
# <add key="PoisonMessageDetectionEnabled" value="false" />"false" />
# After editing, restart Transport
Restart-Service MSExchangeTransportScenario 5: Analyze Crash Dump
# Find crash dump files
$dumpPath = "C:\ProgramData\Microsoft\Windows\WER\ReportArchive"
Get-ChildItem $dumpPath -Recurse -Filter "*.dmp" |
Sort-Object LastWriteTime -Descending | Select-Object -First 5
# For detailed analysis, use WinDbg or send to Microsoft Support
# Dump location also in: %LOCALAPPDATA%\CrashDumps
# Quick stack trace with procdump (if captured)
# procdump -ma EdgeTransport.exe
# Key things to look for:
# - Third-party DLL names in stack
# - Specific Exchange component (categorizer, routing, etc.)
# - Memory address patterns suggesting corruptionVerify the Fix
After addressing poison messages, confirm mail flow is stable:
# 1. Confirm poison queue is empty or manageable
Get-Queue -Identity "Poison" | Select-Object MessageCount
# 2. Verify Transport service stability
Get-Service MSExchangeTransport | Select-Object Name, Status
# Check no restarts in last hour
Get-EventLog -LogName System -Source "Service Control Manager" -Newest 20 |
Where-Object {$_.Message -like "*MSExchangeTransport*"}
# 3. Test mail flow
Send-MailMessage -From "admin@company.com" -To "test@external.com" `
-Subject "Post-Poison Test $(Get-Date)"Get-Date)" -Body "Testing mail flow" `
-SmtpServer localhost
# 4. Check message tracking
Get-MessageTrackingLog -Start (Get-Date).AddMinutes(-10) -EventId DELIVER |
Select-Object Timestamp, Sender, Recipients | Format-Table
# 5. Monitor for new poison events
Get-EventLog -LogName Application -Source MSExchangeTransport -Newest 20 |
Where-Object {$_.EventID -in @(10001, 4010)}Success Indicators:
- Poison queue empty or messages successfully resumed
- Transport service running without restarts
- Test emails delivered successfully
- No new Event IDs 10001 or 4010
- Normal mail flow resumed for all users
Prevention: Reduce Poison Message Risk
1. Keep Exchange and Agents Updated
- Apply Exchange Cumulative Updates quarterly
- Apply Security Updates immediately
- Keep transport agents updated and compatible
- Test updates in lab environment first
2. Configure Message Limits
# Limit message size to reduce oversized message issues
Set-TransportConfig -MaxReceiveSize 35MB -MaxSendSize 35MB
# Limit attachment count and nesting
# These settings help prevent resource exhaustion
Set-TransportConfig -MaxRecipientEnvelopeLimit 500
# Configure connector limits
Get-ReceiveConnector | Set-ReceiveConnector -MaxMessageSize 35MB3. Monitor Poison Queue
# Run hourly via Task Scheduler
$poisonCount = (Get-Queue -Identity "Poison" -ErrorAction SilentlyContinue).MessageCount
if ($poisonCount -gt 0) {
$messages = Get-Message -Queue "Poison" |
Select-Object DateReceived, FromAddress, Subject |
Out-String
Send-MailMessage -To "admin@company.com" -From "alerts@company.com" `
-Subject "Alert: $poisonCount Poison Messages Detected" `
-Body "Messages in poison queue:\n$messages" `
-SmtpServer "backup-smtp.company.com"
}4. Edge Transport Filtering
- Deploy Edge Transport server for perimeter filtering
- Block malformed messages before they reach mailbox servers
- Enable connection filtering and sender reputation
5. Document and Review
- Document every poison message incident
- Track patterns (same sender, similar content)
- Review monthly for trends
- Share findings with security team
Recurring Poison Messages? Let Us Investigate.
If poison messages keep appearing despite updates and agent checks, there may be a deeper compatibility issue or targeted attack. Our mail flow specialists can analyze crash dumps, identify root causes, and implement permanent fixes.
Exchange Poison Message InvestigationAverage Response Time: 15 Minutes
Frequently Asked Questions
Related Exchange Server Errors
Event ID 2004: Message Delivery Failed - Fix Guide 2025
Email delivery failures in Exchange transport. Diagnose NDRs, fix routing, resolve delivery issues.
Event ID 1050: Transport Rule Timeout - Fix Guide 2025
Transport rule execution timeout causing delays. Optimize rules, increase timeout, fix performance.
Event IDs 15004-15007: Back Pressure - Fix Guide 2025
Back pressure activated, throttling Exchange mail flow. Free resources, optimize queues, restore performance.
Still Stuck? We Can Help
If you're still experiencing Event IDs 10001/4010 after following this guide, our Exchange specialists can diagnose and fix the issue quickly.
- Remote troubleshooting in 95 minutes average
- No upfront commitment or diagnosis fees
- Fix-it-right guarantee with documentation
Medha Cloud Exchange Server Team
Microsoft Exchange Specialists
Our Exchange Server specialists have 15+ years of combined experience managing enterprise email environments. We provide 24/7 support, emergency troubleshooting, and ongoing administration for businesses worldwide.