IIS uses worker processes (w3wp.exe file in Windows) to handle client requests. If w3wp.exe crashes, your users cannot access to your application until the process starts again. In Event Viewer, you may see the exception codes 0xc0000005 and 0xe0434352 recorded during crashes.
Exception descriptions from Event Viewer are below. “Faulting module name” refers to the component that causes the crash.
Event ID: 1000
Faulting application name: w3wp.exe, version: 10.0.14393.0, time stamp: 0x57899b8a
Faulting module name: KERNELBASE.dll, version: 10.0.14393.2608, time stamp: 0x5bd1340d
Exception code: 0xe0434352
Event ID: 1000
Faulting application name: w3wp.exe, version: 10.0.14393.0, time stamp: 0x57899b8a
Faulting module name: OraOps12.dll, version: 2.121.1.0, time stamp: 0x52002676
Exception code: 0xc0000005
Solution
Based on the logs above, there are two exception codes that lead to the root cause:
- Exception code 0xc0000005: It translates into STATUS_ACCESS_VIOLATION.
0:000> !err 0xC0000005 0xc0000005 = STATUS_ACCESS_VIOLATION - In our particular case (In the logs above), the faulting module is
OraOps12.dll. This is a part of Oracle Data Access Components (ODAC). Upgrading or repairing the related module could fix the issue. - The best way to identify what exactly caused the problem is to capture a crash dump and examine the faulting thread's call stack. If a regular crash dump does not reveal the root cause, then a pageheap enabled dump may be required for further investigation.
- Exception code 0xe0434352: This is a generic CLR exception code. It is thrown when there is an internal issue in the application. In most cases, it is either
System.NullReferenceExceptionorSystem.ArgumentException - There is no straightforward way to solve these kind of issues. I would recommend debugging the application in Visual Studio to get more details. In case you don’t have access to the source code, you can use DebugDiag or WinDbg for further troubleshooting.
