Seeing all 15 application pools simultaneously fail to respond to pings suggests a system-wide issue rather than individual application problems. The Windows Server 2003 architecture uses a "ping" mechanism where the IIS health monitoring system sends periodic RPC calls to worker processes. When these fail consecutively (default is 5 attempts every 90 seconds), IIS considers the process dead.

For this specific environment running .NET 1.1 applications, several factors could contribute:

// Sample PowerShell to check current ping settings
Import-Module WebAdministration
Get-ChildItem IIS:\AppPools | Select-Object Name, PingInterval, PingResponseTime

1. Resource starvation: Check for memory leaks or CPU spikes around the failure time using PerfMon counters:

Processor(_Total)\% Processor Time
Memory\Available MBytes
Process(w3wp)\Private Bytes

2. Network/DCOM issues: The ping mechanism uses RPC over DCOM. Verify DCOM security settings:

dcomcnfg.exe → Component Services → Computers → My Computer → DCOM Config

3. Deadlock scenarios: Especially critical in .NET 1.1 apps where thread pool starvation was more common.

Create a dump file when the issue occurs:

procdump -ma -n 3 -s 30 w3wp.exe

Analyze startup delays using Process Monitor:

procmon.exe /AcceptEula /BackingFile iis_startup.pml
procmon.exe /OpenLog iis_startup.pml

Modify application pool settings in applicationHost.config:

<applicationPools>
    <add name="Pool31x" autoStart="true" startMode="AlwaysRunning">
        <processModel identity="NetworkService" 
                      pingInterval="00:00:30" 
                      pingResponseTime="00:01:30"/>
    </add>
</applicationPools>

Consider these emergency adjustments:
- Increase pingResponseTime from default 90 seconds
- Set shutdownTimeLimit higher than default 90 seconds
- Enable overlapped recycling

For legacy .NET 1.1 applications:
1. Implement a custom health monitor page

// Sample ASP.NET 1.1 health check
<%@ Page Language="C#"%>
<%
    try {
        SqlConnection testConn = new SqlConnection(connString);
        testConn.Open();
        testConn.Close();
        Response.Write("OK");
    }
    catch (Exception ex) {
        Response.Write("FAIL: " + ex.Message);
    }
%>

2. Consider upgrading to application warmup modules
3. Move critical pools to dedicated AppPool identities

Create an automatic recovery script:

@echo off
for /F "tokens=2 delims=," %%G in (
    'type %SystemRoot%\System32\inetsrv\config\applicationHost.config ^| 
     find "application pool"'
) do (
    %SystemRoot%\System32\inetsrv\appcmd recycle apppool /apppool.name:"%%G"
)

---

When multiple IIS application pools simultaneously fail to respond to ping requests, it typically indicates a systemic issue rather than isolated application problems. The Windows System Log entry "A process serving application pool 'Pool 31x' failed to respond to a ping" suggests the worker processes became unresponsive to IIS health monitoring.

Simultaneous failures across 15 pools suggest either:

• Resource exhaustion (CPU, memory, or I/O saturation)
• Deadlock in shared components
• External dependency failure (like database connection storms)
• Windows ISAPI filter issues with .NET 1.1

Check these performance counters during incidents:

# PowerShell snippet to monitor critical counters
Get-Counter -Counter "\Process(w3wp)\% Processor Time",
                    "\Memory\Available MBytes",
                    "\ASP.NET Applications\Requests/Sec",
                    "\SQLServer:General Statistics\User Connections"

Legacy .NET frameworks exhibit known issues under load:

• ThreadPool starvation due to synchronous DB calls
• Garbage collection freezes in low-memory scenarios
• ISAPI request queue limits

Example mitigation for connection pooling:

// Web.config adjustment for legacy apps
<system.web>
  <processModel autoConfig="false"
    maxWorkerThreads="100"
    maxIoThreads="100"
    minWorkerThreads="50"/>
  <httpRuntime minFreeThreads="88" />
</system.web>

Slow pool restarts often indicate:

1. Cold starts of .NET 1.1 frameworks
2. Precompilation bottlenecks
3. Database connection warmup delays

Add this registry tweak to accelerate .NET 1.1 loading:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\1.1.4322.0]
"StartupTimeLimit"="30"

Implement this PowerShell health check script:

function Test-AppPoolHealth {
    param([string]$server = "localhost")
    
    $pools = Get-WmiObject -Namespace "root\MicrosoftIISv2" 
             -Class "IIsApplicationPool" -ComputerName $server
    
    $results = @()
    foreach ($pool in $pools) {
        $status = (Get-WmiObject -Namespace "root\MicrosoftIISv2" 
                  -Query "SELECT * FROM IIsApplicationPool WHERE Name='$($pool.Name)'" 
                  -ComputerName $server).AppPoolState
        
        $results += [PSCustomObject]@{
            Name   = $pool.Name
            Status = $status
            PID    = (Get-Process -IncludeUserName -Name w3wp |
                    Where-Object { $_.UserName -like "*$($pool.Name.Replace('/','').Replace('W3WC',''))*" }).Id
        }
    }
    return $results
}

When mass failures occur:

1. Reset IIS cache: iisreset /noforce
2. Clear .NET temp files: del /q /f /s %WINDIR%\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\*
3. Recycle all pools: Get-IISAppPool | ForEach-Object { $_.Recycle() }