It is not the 1st, and probably not last, I got this kind of problems...
But we got a server with a “freezed” Web console (opening from an external IE8 on Windows 7 x64)
about once time per hour, during 3 to 15 mn. When “a long time” freeze, the console “reset” asking again for the Windows credential (Just cancel & refresh the page is OK)...
What’s happen: simple: Cycling the application pool, the W3WP kill himself, and restart a new process ID...
Log Name: System
Source: Microsoft-Windows-WAS
Event ID: 5010
Task Category: None
Level: Warning
Keywords: Classic
Description:
A process serving application pool 'Classic .NET AppPool' failed to respond to a ping. The process id was '13520'.
Some our customers solve it creating its own “application pool”, but why ? With which options?
And why for some install, and not others?
How can we fix this definitively, and prevent for any further installations?
I see a few nice things in there:
https://www-secure.symantec.com/connect/blogs/creating-new-iis-application-pools-magic-solution-smp-7-slow-console-operations (Thanks Ludovic), but not all answers.
Should we simply create another application pool ?
But for which of the 78 current applications ?
What should we do with the 17 appplications keep under “DefaultAppPool”, and not freezing.
I create a Symantec case escalation (# 414-250-394) for getting confirmation.
We currently install CMS+SMS+AMS 7.1 on a Windows Server 2008 R2 (Build 7600)
IIS is 7.5.7600.16385
Should be a standard Windows installation... Using only one disk C.
Hosted on a standard ESX server.
Using an external SQL database 2008.
IIS activation and settings were defined as standard from the SIM installer (creating the “Classic Pool”?)
(hum, I put the JGP below in att. to see better)
How can we stop this mess ?
I do not find any significative KB related this problem:
- TECH14723 makes me adding the "Fixed nb of request" for 35'000 into the Recycling conditions, without result
- I do not see any entry in log corresponding the TECH22026.
I see only those in Altiris logs:
Process: w3wp (14092)
Thread ID: 265
Module: w3wp.exe
Source: Altiris.NS.Server.GroupMessaging_Trace
Description: [w3wp.exe:/LM/W3SVC/1/ROOT/Altiris/Console-7-129457842206370590] <_lm_w3svc_1_root_altiris_console_7_129457842206370590_76e993ba7be2480da4e0de569b1b3fe1>:<ReliableMMF> Bad packet received (hash failure).