Application crashes on app pool 1, but doesn't on app pool 2

StackOverflow https://stackoverflow.com/questions/23489331

Domanda

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
È stato utile?

Soluzione

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:

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

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top