应用程序在应用程序池1上崩溃，但不在应用程序池2上崩溃

Question

I have rather extensive silverlight application with which our customers work.

Currently we have an issue where the application pool will crash with the following message:

"A process serving application pool 'app pool 1' suffered a fatal communication error with the Windows Process Activation Service. The process id was '6308'. The data field contains the error number."

When I try the same action on local, it works perfectly. When I try the same action on a difference application pool, it works perfectly.

Here's a bunch of stuff i've tried already:

• Change app pool 1 to app pool 2 in crashing application. Still crashes the app pool
• Duplicated the application from visual studio and put it on a different app pool (app pool 2). Works perfectly, when set to app pool 1, works perfectly
• checked all settings (app pool + advanced settings, website + advanced settings). Everything is the same
• Turned on Process Monitor, but it didn't show me anything usefull.

I have no idea what to try next to fix this problem!

Anyone have any suggestions?

ps. sometimes I get the following error in Windows Logs > Application, but since we are running a lot of applications on the server I can't see if it applies to this problem or not

• Faulting application name: w3wp.exe, version: 7.5.7601.17514, time stamp: 0x4ce7afa2
• Faulting module name: clr.dll, version: 4.0.30319.1, time stamp: 0x4ba21eeb
• Exception code: 0xc00000fd
• Fault offset: 0x000000000000850a
• Faulting process id: 0x21fc
• Faulting application start time: 0x01cf690216e7002c
• Faulting application path: c:\\windows\\system32\\inetsrv\\w3wp.exe
• Faulting module path: C:\\Windows\\Microsoft.NET\\Framework64\\v4.0.30319\\clr.dll
• Report Id: 61fc36e4-d4f5-11e3-9d58-0050569738fa

Answer 1

Exception code: 0xc00000fd indicates that your application is failing with a stack overflow exception.

This is most commonly caused by code that uses recursion never unwinding the stack.

The only real way to find out is to capture a process dump with ADPlus/Debug Diagnostic Tools and load it up into WinDbg and SOS for analysis. Tess Ferrandez, who was an escalation engineer for MS, has a great series of blogs on how to use these tools:

• http://blogs.msdn.com/b/tess/archive/2008/02/04/net-debugging-demos-information-and-setup-instructions.aspx

• http://blogs.msdn.com/b/tess/archive/2008/02/08/net-debugging-demos-lab-2-crash.aspx

• http://blogs.msdn.com/b/tess/archive/2008/03/05/net-debugging-demos-lab-5-crash.aspx

There's even an article specifically about how to look for a stack overflow culprit:

• http://blogs.msdn.com/b/tess/archive/2008/03/31/net-case-study-stackoverflow-exception-when-using-a-complex-rowfilter.aspx