This post has been republished via RSS; it originally appeared at: IIS Support Blog articles.
Consider the following scenario:
- You are running a web application on IIS and you need to collect a memory dump of the application pool process (w3wp.exe), e.g.: when trying to troubleshoot a performance issue.
- w3wp.exe consumes large memory and it takes long time to write the dump file.
- When you try to collect a memory dump of the worker process, it is terminated and the memory dump is corrupted.
At the same time you may see the following event logged in the system event logs:
Log Name: System
Source: Microsoft-Windows-WAS
Date: <date of the issue>
Event ID: 5010
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: <name of the computer>
Description:
A process serving application pool 'AppPool name' failed to respond to a ping. The process id was '<PID>'.
This may be happening due to the “health monitoring” configuration of the application pool. Let's see what happens. The following screenshot shows the default settings for health monitoring:
The following happens with the default configuration seen in the screenshot above:
- WAS monitors the application pool by "pinging" it every 30 seconds (Ping Period configuration).
- If the process does not respond in 90 seconds (Ping Maximum Response Time) then WAS will terminate the process considering that it is unhealthy.
Remember that a process (actually its threads) is suspended when a dump is written to the disk, which means that it will not respond to WAS’ ping requests until the dump file is written. If it takes longer time to write the dump file than the "Ping Maximum Response Time", then WAS will terminate the process.
If you see the similar behavior and you need to collect a useful dump then you may need to increase the ping timeout or set “ping enabled” to false until you collect the memory dump (which is not recommended). Please note that these changes will cause application pool recycle.
This story actually explains why it is important to capture the memory dumps in a local folder instead of a network share. The dump file should be written as fast as possible so the process is not suspended for a long time.
Happy troubleshooting...
--
AMB