In my winforms application I get the following exception at random occasions:
Application: My.Shell.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AccessViolationException
Stack:
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG ByRef)
at System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)
at System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)
at System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)
at System.Windows.Forms.Application.Run(System.Windows.Forms.Form)
at Microsoft.Practices.CompositeUI.WinForms.FormShellApplication`2[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089],[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].Start()
at Microsoft.Practices.CompositeUI.CabApplication`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].Run()
at My.Shell.ModuleLoader.Main()
The stacktrace was from the windows event-viewer. (The unandeled exception handler did not get it.)
I read many articles regarding this on SO:
- C# WinForms exception: A first chance exception of type 'System.AccessViolationException'
- finding the cause of System.AccessViolationException
- AccessViolationException from System.Windows.Forms, using WinFormsHost in WPF
- AccessViolationException from a combo: Attempted to read or write protected memory
It turns out that my application somwhere accesses disposed or corrupted memory throug a native method. My question now is how to find that location using a crashdump that I made with the taskmanager. Are there other strategies to find the cause?
It would probably help to use SOS and break on the first unhandled exception and go from there.
You can also dynamically launch the debugger if required. See 'System.Diagnostics'.
This will allow you to take an overview of the condition which caused or allowed the exception to occur as well as be able to follow it without waiting for the error to occurs while the debugger is attached.