Consider the following scenario:
At the same time you may see the following event logged in the system event logs:
Log Name: System
Date: <date of the issue>
Event ID: 5010
Task Category: None
Computer: <name of the computer>
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:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.