I've encountered a NullReferenceException that is not handled by the MVC global error event handler (Application_Error). This is only happening in production. The IIS application pool shuts down after five failures due to the Rapid-Fail Protection IIS settings. There's only one application in the pool.
Below is a snippet from a .wer (Windows Error Reporting) file. It contains information about the unhandled exception. My understanding is Sig[6] contains the important value. I used the value e3 (227 in decimal) to find the method signature in IL code.
EXE File name: Sig[0].Value=w3wp.exe
EXE File Assembly Version: Sig[1].Value=7.5.7601.17514
EXE File Stamp: Sig[2].Value=4ce7afa2
EXE File Full Assembly Version: Sig[3].Value=System.Web
Faulting Assembly Version: Sig[4].Value=4.7.3282.0
Faulting Assembly Timestamp: Sig[5].Value=5bd8e3e7
Faulting Assembly Method Def: Sig[6].Value=e3
Faulting Method IL Offset: Sig[7].Value=25
Exception Type: Sig[8].Value=System.NullReferenceException
The value of Sig[6] translates to the token 06000227. The instructions for translating from e3 to 06000227 can be found here.
.method /*06000227*/ private hidebysig newslot specialname virtual final
instance bool System.Web.HttpApplication.IExecutionStep.get_IsCancellable() cil managed
{
.override System.Web.HttpApplication/*0200003A*//IExecutionStep/*0200003F*/::get_IsCancellable /*0200003F::0600020B*/
// Code size 2 (0x2)
.maxstack 8
IL_0000: ldc.i4.0
IL_0001: ret
} // end of method MapHandlerExecutionStep::System.Web.HttpApplication.IExecutionStep.get_IsCancellable
Provided I did the translation correctly, why would IsCancellable throw/cause a NullReferenceException? Is there more for me to trace up the call stack? The fact that the error is coming from System.Web is confusing me.
Other event handlers used in the global.asax:
Application_PreRequestHandlerExecute
Application_BeginRequest
Application_AuthenticateRequest
Please let me know if you need more details.
Thank you for your help.
Related
The application is running on multiple clients. Today I had an incident, where after a power failure, the application was not starting again.
Following are the exceptions from the event log
Faulting application name: MyApplication.exe, version: 7.3.0.14, time stamp: 0x626786ff
Faulting module name: KERNELBASE.dll, version: 6.1.7601.24561, time stamp: 0x5f76968d
Exception code: 0xe0434352
Fault offset: 0x0000c5af
Faulting process id: 0xeb4
Faulting application start time: 0x01d8d17277e726c1
Faulting application path: C:\Program Files (x86)\MyCompany\Visu\MyApplication.exe
Faulting module path: C:\Windows\syswow64\KERNELBASE.dll
Report Id: b5b2baf1-3d65-11ed-b8b3-00139548ead0
Detailed exception
Application: MyApplication.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.Xml.XmlException
at System.Xml.XmlTextReaderImpl.Throw(System.Exception)
at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
at System.Xml.XmlTextReaderImpl.Read()
at System.Xml.XmlTextReader.Read()
at System.Configuration.XmlUtil..ctor(System.IO.Stream, System.String, Boolean, System.Configuration.ConfigurationSchemaErrors)
at System.Configuration.BaseConfigurationRecord.InitConfigFromFile()
Exception Info: System.Configuration.ConfigurationErrorsException
at System.Configuration.ConfigurationSchemaErrors.ThrowIfErrors(Boolean)
at System.Configuration.BaseConfigurationRecord.ThrowIfParseErrors(System.Configuration.ConfigurationSchemaErrors)
at System.Configuration.BaseConfigurationRecord.ThrowIfInitErrors()
at System.Configuration.ClientConfigurationSystem.OnConfigRemoved(System.Object, System.Configuration.Internal.InternalConfigEventArgs)
Exception Info: System.Configuration.ConfigurationErrorsException
at System.Configuration.ClientConfigurationSystem.OnConfigRemoved(System.Object, System.Configuration.Internal.InternalConfigEventArgs)
at System.Configuration.Internal.InternalConfigRoot.OnConfigRemoved(System.Configuration.Internal.InternalConfigEventArgs)
at System.Configuration.Internal.InternalConfigRoot.RemoveConfigImpl(System.String, System.Configuration.BaseConfigurationRecord)
at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(System.String, Boolean, Boolean, Boolean, Boolean, System.Object ByRef, System.Object ByRef)
at System.Configuration.BaseConfigurationRecord.GetSection(System.String)
at System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection(System.String)
at System.Configuration.ConfigurationManager.GetSection(System.String)
at Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceSection.GetConfigurationSourceSection()
at Microsoft.Practices.EnterpriseLibrary.Common.Configuration.ConfigurationSourceFactory.Create()
at Microsoft.Practices.EnterpriseLibrary.Common.Configuration.EnterpriseLibraryContainer.CreateDefaultContainer()
at Microsoft.Practices.EnterpriseLibrary.Common.Configuration.EnterpriseLibraryContainer.SetCurrentContainerIfNotSet()
at Microsoft.Practices.EnterpriseLibrary.Common.Configuration.EnterpriseLibraryContainer.get_Current()
at Microsoft.Practices.EnterpriseLibrary.Logging.Logger.get_Writer()
at Microsoft.Practices.EnterpriseLibrary.Logging.Logger.Write(System.Object, System.String, Int32, Int32)
at MyApplication.App.Main(System.String[])
Code:
[System.STAThreadAttribute()]
public static void Main(string[] args)
{
Logger.Write("Application was started on:" + DateTime.Now, "Core", 100, 100);
...
}
As I had no possiblity for remote debugger, I copied the complete application folder from the client to my dev machine. Everything was working properly. The application started and the UI was displayed.
On the client machine I tried the following
checked the application.config file - everything OK
starting the application with administrative rights - same exception
moving the folder from the "program files" directory to somewhere different, including all configuration files - same exception
comparing the current application folder with initial folder after the setup, all files are equal - same exception
As a last point, i updated the code of the main method with a try catch block around the call to the Enterprise Logger. I compiled the exe and started the updated version on the client computer. Only the exe and manifest file have been updated!
The application started and the catch block was never triggered.
I switched back to the "previously corrupted?" version and now it was successfully running.
From the text i assume that something must be wrong the the app.config file. But then it would also throw the exception on my dev machine and would still throw the exception after the update of the app.exe.
What could be the reason of the above exception?
With the tips from #PanagiotisKanavos the solution of the problem was possible.
Checking the file access with procmon, i realised that there was a user.config file stored at C:<Users><Username>\AppData\Local<MyCompany><MyApp><AppVersion>.
This file was corrupt - filled with '\0' - due to the power failure.
At startup the user.config file was merged with the app.config file and this crashed the application.
I am trying to track down an error occurring on a target machine running Windows 7 64-bit for a C# WinForms application written in Visual Studio 2008. All I have to go on is the Windows Error Reporting output from the Event Viewer. I found a lot of helpful information here: http://www.codeilove.com/2012/09/debugging-using-windows-error-reporting.html.
Problem signature:
P1: myprogram.exe // filename of the executable
P2: 1.44.0.0 // assembly version for the executable in P1
P3: 560be2df // assembly timestamp for the executable in P1
P4: mscorlib // assembly where the fault occurred
P5: 2.0.0.0 // assembly version for the assembly in P4
P6: 4ca2b889 // assembly timestamp for the assembly in P4
P7: c43 // token for the method where the fault occurred
P8: 59 // IL offset into the method specified in P7
P9: System.FormatException // name of the exception that caused the fault
From the link it appears that P7, P8, and P9 are the most important, and that I should be able to find the method def for "c43" using ILDASM by looking for 06000c43. In C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll I find the following in System.Number:
.method /*06000C43*/ assembly hidebysig static
uint64 ParseUInt64(string 'value',
valuetype System.Globalization.NumberStyles/*020003B6*/ options,
class System.Globalization.NumberFormatInfo/*020003B5*/ numfmt) cil managed
Based on this information there is a System.FormatException occurring in System.Number.ParseUInt64, right? I have searched through my project in Visual Studio, and I can't find any instances where my code calls this function. Where do I go from here?
I have a top-level exception handler for Application.ThreadException that logs unhandled exceptions to a file. In this case I am getting an application crash and nothing in my log file. Is it safe to assume this Exception is happening in a thread other than my UI?
Starting with Vista SP1 you can configure Windows Error Reporting to collect local crash dumps. Just set registry settings on the target machine as described in that article and wait till your program crashes again. After that, check the directory that you've configured as DumpFolder. You should find a .dmp file in there. Open it in WinDbg or with Visual Studio and you should be able to see a full stack trace of where the exception happened.
I'm trying to decipher the meaning on the P1...P10 parameters associated with a clr20r3 that is written to the event log when my application experiences an exception.
The best I've been able to find is:
P1: the hosting process (e.g. w3wp.exe)
P2: the hosting process version (e.g. 6.0.3790.1830)
P3: ??? (e.g. 42435be1)
P4: the assembly from which the exception was raised (e.g. mrtables.webservice)
P5: the assembly version (e.g. 2.1.2.0)
P6: ??? (e.g. 4682617f)
P7: ??? (e.g. 129)
P8: ??? (e.g. 50)
P9: the exception type raised (e.g. system.argumentexception)
P10: ??? (e.g. NIL)
Googling for clr20r3 provides thousands of sample parameter values, from which someone can try to derive a pattern.
But I'm hoping for documentation on the parameter meanings, as opposed to educated guesses.
Edit: While I can hope for canonical documentation, really I'd be happy to see the exception being thrown, at what line, complete with a stack trace.
Bonus Reading
Unhandled exception that caused the application to crash with "EventType clr20r3, P1 w3wp.exe" in the log, but no details there (asking for help with a problem, while we're asking for a canonical explanation of what the parameters mean)
P7 and P8 are the important ones to find out where the P9 exception was raised. Use P4 to know what assembly to look for. Run ildasm.exe and open that assembly. File + Dump, tick the "Token values" checkbox, OK and save the .il file somewhere.
Open the file in a text editor. P7 gives you the method token, it starts with 0x06, producing token value "06000129". Search for:
.method /*06000129*/
Which gives you the method name, look up from there to find the .class, that gives you the class name.
P8 gives you the IL offset. From the found .method, look for IL_0050 for the instruction that raised the exception. Mapping it back to your source code is a bit tricky but you'll probably figure it out. Use Reflector if necessary.
In general, write an event handler for AppDomain.UnhandledException to avoid the pain of reverse-engineering these Watson crash buckets. Log the value of e.ExceptionObject.ToString() to get both the exception message and a stack trace.
Here is the information on Watson Buckets
Exe File Name
Exe File assembly version number
Exe File Stamp
Exe file full assembly name
Faulting assembly version
Faulting assembly timestamp
Faulting assembly method def
Faulting method IL Offset within the faulting method
Exception type
And also here is a MSDN article on the same.
Sample:
Problem Signature 01: devenv.exe
Problem Signature 02: 11.0.50727.1
Problem Signature 03: 5011ecaa
Problem Signature 04: Microsoft.VisualStudio.SharePoint.Project
Problem Signature 05: 11.0.60226.0
Problem Signature 06: 512c2dba
Problem Signature 07: 18a8
Problem Signature 08: 1d
Problem Signature 09: System.NullReferenceException
We are getting the following error from a .NET Application:
Faulting application name: OurApplication.exe, version: 1.0.10603.0, time stamp: 0x556f0756
Faulting module name: KERNELBASE.dll, version: 6.1.7601.18409, time stamp: 0x53159a86
Exception code: 0xe053534f
Fault offset: 0x0000c42d
Faulting process id: 0x
Faulting application start time: 0x
Faulting application path:
Faulting module path:
Report Id:
OurApplication.exe has a handler for AppDomain.CurrentDomain.UnhandledException and Application.ThreadException. What am I missing?
Per Hans Passant:
The exception code tells the tale, 53534f are the ASCII codes for "SSO". A Soft Stack Overflow. Midly softer than a hard stack overflow, the runtime can tell that a hard stack overflow is guaranteed when setting up the stack frame for a call. No space left to make the call so it pulls the plug early. Otherwise treated the exact same way, StackOverflowException is a fatal error and always instantly crashes your app. Always a bug in your code, there are many questions about it here
This was also a great article:
http://blog.fogcreek.com/production-debugging-a-story-about-exception-code-0xe053534f/
I have an apllication written in .net C# and it sporafdically crashes (not responding) the windows event log ahd the following message.
(teh dll it refers to is unmanaged code)
does anyone know what does this exception mean? what might cause this? and what are the ways to solve this?
Faulting application name: Application.exe, version: 4.2.11.0, time stamp: 0x4e8d8e86
Faulting module name:myDll.DLL_unloaded,
Exception code: 0xc0000005
Fault offset: 0x0000000180004d3c
Faulting module path: myDll.DLL
Report Id: 5608bfd7-f014-11e0-9df7-001cc05d00b7
thanks!
It means that MyDll.DLL was unloaded while it still had active code (either running at the time, or waiting to run because it is on the stack or is registered as a callback), so when the program went to execute the code, there was no code there any more. You need to investigate why your DLL is being unloaded and prevent it from being unloaded while it is still has active code.