Event IDs 10001/4010

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.

Medha Cloud
Medha Cloud Exchange Server Team
Exchange Database Recovery Team12 min read

Table of Contents

Reading Progress
0 of 9

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.

Typical Event Log Entries
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

1
First CrashMessage processing fails, service restarts
2
Second CrashSame message fails again, crash count incremented
3
Third CrashMessage moved to Poison queue, Event 10001 logged
Service StabilizesNormal mail flow resumes

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:

Step 1: View Poison Queue Contents
# 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 -AutoSize

What 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?
Step 2: Examine Specific Poison Message
# 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.

Step 3: Export Poison Message for Analysis
# 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")
}
Step 4: Check Event Logs for Crash Details
# 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*"}
Step 5: Check Transport Agent Involvement
# 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, journaling

Quick Fix (10 Minutes) - Clear Poison Queue

Option A: Delete Poison Messages (If Spam/Malicious)

Remove Poison Messages
# 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 Poison 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 for Manual Handling
# 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 method

Detailed Solution: Prevent Recurrence

Scenario 1: Transport Agent Causing Crashes

Identify and Fix Problem Agent
# 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 content

Scenario 2: Exchange Bug - Apply Updates

Check and Apply Exchange 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

Block Source of Poison Messages
# 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.

Modify Poison Detection Settings
# 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 MSExchangeTransport

Scenario 5: Analyze Crash Dump

Advanced: 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 corruption

Verify the Fix

After addressing poison messages, confirm mail flow is stable:

Verification Commands
# 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

Set Protective 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 35MB

3. Monitor Poison Queue

Poison Queue Monitoring Script
# 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 Investigation

Average Response Time: 15 Minutes

Frequently Asked Questions

A poison message is an email that crashes the Transport service when Exchange attempts to process it. After a message causes three consecutive crashes, Exchange moves it to the Poison Message queue to protect mail flow. The message typically contains malformed headers, corrupted content, or triggers a bug in a transport agent.

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
Get Expert Help
95 min
Average Response Time
24/7/365 Availability
Medha Cloud

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.

15+ Years ExperienceMicrosoft Certified99.7% Success Rate24/7 Support