CODEWITHSUNDEEP
c#.netwinformsdebuggingwindb
schoetbi
schoetbi

Reputation: 12856

C# Winforms: Debug strategies to find cause for System.AccessViolationException

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:

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?

Upvotes: 3

Views: 1844

Answers (3)

kjbartel
kjbartel

Reputation: 10581

I've found that the UnhandledException and ThreadException events are often not triggered in WinForms. In my application I have three different ways to catch an unhandled exception. Often it's just the try catch which gets it.

static void Main(string[] args)
{
    Application.ThreadException += Application_ThreadException;
    Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);
    AppDomain.CurrentDomain.UnhandledException += CurrentDomain_UnhandledException;

    try
    {
        var mform = new MainForm();
        Application.Run(mform);
    }
    catch (Exception ex)
    {
        HandleException(ex);
    }
}

private void Application_ThreadException(object sender, ThreadExceptionEventArgs e)
{
    HandleException(e.Exception);
}

private void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
    HandleException(e.ExceptionObject as Exception);
}

private void HandleException(Exception ex)
{
    // Do something with it
}

Upvotes: 1

schoetbi
schoetbi

Reputation: 12856

I ended with this wonderful tool: "Debug Diagnostic Tool" from Microsoft. See the details on CodeProject

"The Debug Diagnostic Tool (DebugDiag) is designed to assist in troubleshooting issues such as hangs, slow performance, memory leaks or fragmentation, and crashes in any user-mode process." (microsoft.com) DebugDiag Tool is much simpler to use compared to other tools for debugging.

The tool automaticaly monitors a specific process and saves dumpfiles into a selectable folder. Very convenient ;-)

Upvotes: 0

Jay
Jay

Reputation: 3355

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.

Upvotes: 0

Related Questions