Application server is crashing every after 4-5 days RRS feed

  • 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>

    Thursday, May 17, 2018 5:19 AM

All replies

  • 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.


    Thursday, May 17, 2018 6:23 AM
  • 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.

    Saturday, May 19, 2018 3:08 AM