Menu

How to debug an IIS FailFast error that is causing dbFront to crash?

0 votes

The dbFront web application fails, and when I look in the eventlog it shows the following two eventlog entries:

EventLog Entry 1


Application: w3wp.exe
Framework Version: v4.0.30319
Description: The application requested process termination through System.Environment.FailFast(string message).
Message:
Stack:
at System.Environment.FailFast(System.String)
at .‮‏‎‮​‌​‬‏‫‫‌‬‍‭‌‪‬‬‮()
at ..cctor()
at System.RuntimeTypeHandle.CreateInstance(System.RuntimeType, Boolean, Boolean, Boolean ByRef, System.RuntimeMethodHandleInternal ByRef, Boolean ByRef)
at System.RuntimeType.CreateInstanceSlow(Boolean, Boolean, Boolean, System.Threading.StackCrawlMark ByRef)
at System.RuntimeType.CreateInstanceDefaultCtor(Boolean, Boolean, Boolean, System.Threading.StackCrawlMark ByRef)
at System.Activator.CreateInstance(System.Type, Boolean)

EventLog Entry 2


Faulting application name: w3wp.exe, version: 10.0.17763.1, time stamp: 0xa7ccada2
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0x80131623
Fault offset: 0x263668d2
Faulting process id: 0x2338
Faulting application start time: 0x01dc0d50b3aaa70e
Faulting application path: C:\Windows\SysWOW64\inetsrv\w3wp.exe
Faulting module path: unknown
Report Id: ab6204e7-6324-441a-b1fc-5ab9d78205a9
Faulting package full name:
Faulting package-relative application ID:

in Errors by (7.4k points)

1 Answer

0 votes

FailFast errors (COR_E_FAILFAST, 0x80131623) are a special class of Windows errors that can't be caught and so there is no opportunity to create application-specific logs. They are usually thrown when there is no hope of recovery or when recovery is being intentionally blocked (e.g. Antivirus)

In order to further debug this failure you can create a memory dump using Windows Error Reporting (WER) and examine it using Microsoft DebugDiag (http://debugdiag.com/).

To create a memory dump, the simplest option is to load the following Reg file.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\w3wp.exe]    
"DumpFolder"=hex(2):63,00,3a,00,5c,00,64,00,75,00,6d,00,70,00,73,00,00,00    
"DumpCount"=dword:00000002    
"DumpType"=dword:00000002

This will make 2 full user dumps when the error is next raised. These are not mini-dumps but full memory dumps. The reg entry instructs WER to write the dumps to C:\dumps. The memory dumps can be about 250 meg in size but they compress very well using ZIP.

Source: Steps to catch a simple crash dump of a crashing-process, for more detailed instructions.

Once the memory dumps are created you can examine them using DebugDiag. The best place to examine the dump file is directly on the faulting server. This is because all of the correct symbol files will be present. Otherwise you can spend extra time hunting for and loading dependencies.

If the DebugDiag Analysis Summary points to dbFront.dll!Unknown... then it most likely means that some external process interupted the dbFront WebApplication from loading. dbFront does not raise any FastFail errors.

Please let us know any findings.

At the moment, the only source of these errors is Dynatrace OneAgent. For more details see: DynaTrace OneAgent causing dbFront WebApp Failure

by (65.4k points)
Welcome to the dbFront Q&A site, where you can ask questions and receive answers from other members of the community.
 | Minimalist Answer Theme by Digitizor Media
 |
Powered by Question2Answer
...