Application server is crashing every after 4-5 days

Question

User-1371469613 posted

Hi All,

after every 4-5 days web application server get crashed and after restarting sever its working fine. please help me if anyone have solution or any suggestion. below error message are genreted in event log.

<b>Faulting application name: w3wp.exe, version: 10.0.14393.0, time stamp: 0x57899135
Faulting module name: mscorlib.ni.dll, version: 4.6.1586.0, time stamp: 0x575a1299
Exception code: 0xc00000fd
Fault offset: 0x00371983
Faulting process id: 0x1630
Faulting application start time: 0x01d3e3a513e484f0
Faulting application path: C:\Windows\SysWoW64\inetsrv\w3wp.exe
Faulting module path: C:\Windows\assembly\NativeImages_v4.0.30319_32\mscorlib\40571abae9422cd2ca6fafbbde1c3cdc\mscorlib.ni.dll
Report Id: ff408c3f-e685-494f-afb8-f0c66a19eb8f
Faulting package full name:
Faulting package-relative application ID:</b>

Answer 1

User1120430333 posted

WPW3.exe is the ASP.NET Worker Process that services an Application Pool on IIS with the Application Pool hosting an ASP.NET Web program. All ASP.NET programs run under the context of an ASP.NET Worker Process for a given App. Pool. So you have to determine what  is the Application Pool that WPW3.exe is servicing, at the time of the crash.  And then you have to systematically remove programs out of the Application Pool putting the program in another Application Pool possibly for isolation,  until you find the program that is crashing  the Application Pool. 

You may get further help at the IIS forums on how to pinpoint what Web program is crashing the App. Pool.

https://forums.iis.net/

Answer 2

User465171450 posted

And 0xc00000fd is a very generic error that essentially means there was an unknown error. the mscorlib.ni.dll is a natively compiled image of the mscorlib, or core .net library. What cased the failure though is a whole other matter and will often require more tracing to find out. Look for warnings from the asp.net process in the logs. ALso, if you can, add some error logging into the application itself so you can have a chance to see what it may have been doing around the time of the failure.