Question

I have a C# WPF application, and am trying to figure out a way to use dump files to pin-point crash locations with Visual Studio 2010. I'm using SysWow64\TaskMgr.exe to obtain my crash dumps which hover around 500MB.

Here's my Startup code, which uses Visual Basic workaround to ensure I only have a single instance running.

using System;
using Microsoft.VisualBasic.ApplicationServices;

namespace UselessCrashDump
{
    public class Startup
    {
        [STAThread]
        public static void Main(string[] args)
        {
            SingleInstanceManager singleInstanceManager = new SingleInstanceManager();
            singleInstanceManager.Run(args);
        }
    }

    // Using VB bits to detect single instances and process accordingly:
    //  * OnStartup is fired when the first instance loads
    //  * OnStartupNextInstance is fired when the application is re-run again    
    public class SingleInstanceManager : WindowsFormsApplicationBase
    {
        App _app;

        public SingleInstanceManager()
        {
            this.IsSingleInstance = true;
        }

        protected override bool OnStartup(Microsoft.VisualBasic.ApplicationServices.StartupEventArgs e)
        {
            //first launch
            _app = new App();
            _app.InitializeComponent();
            _app.Run();

            return false;
        }

        protected override void OnStartupNextInstance(StartupNextInstanceEventArgs eventArgs)
        {
            //subsequent launches
            base.OnStartupNextInstance(eventArgs);
            _app.Activate();
        }
    }
}

Now inside my application I added a piece of code that will crash it on purpose, after I press a button. The code looks like following:

private void _crash_Click(object sender, RoutedEventArgs e)
{
   CrashMe(null);          
}

private void CrashMe(string someString)
{
   someString.Split(' ');
}

Sure enough, after I run the exe and click the button the program crashes. I then obtain the crash dump, open it, and this is what I see: enter image description here

I was expecting for the code to break at the specific location of the crash. But instead the crash dump points to the entry point to the program. This happens for all crashes. I would like to see exact location of the crash, the way it happens during Debug session.

What am I doing wrong? The dump file itself seems to be loading the PDB file, at least judging by the output:

'[MyApp].DMP' (Managed): Loaded 'C:\Program Files (x86)\[MyCompany]\[MyApp].exe', Symbols loaded.

It doesn't seem to be loading native symbols, but I figured since it's a managed app, I don't need them:

'[MyApp].DMP': Loaded 'C:\Program Files (x86)\[MyCompany]\[MyApp].exe', No native symbols in symbol file.
Was it helpful?

Solution

Taking the dump with task manager at the time of an exception is not very reliable. Try SysInternals ProcDump -e -ma -x "my.exe" "my.dmp" instead or configure Windows Error Reporting to create local dumps (set dump type to 2 / full).

Once you have a good dump, Visual Studio should show something in the field Exception code after opening the dump. I guess that your field looks quite empty at the moment like mine (see screenshot).

Screenshot

If the dump is ok, it should have an exception code inside:

enter image description here

OTHER TIPS

First of all your code doesn't have any try catch statements. When your code crashes it is sending the exception to the upper handler. In your code the latest handler is Main void itself so that's why you are seeing that part.

In addition, you don't need Native Symbols. Native Symbols are COM DLL files which you don't need in this example.

Found the solution to my problem. There were actually two issues:

1) Turns out dump files generated using Task Manager do not contain exception information (this is noted in this article: http://blogs.msdn.com/b/debugger/archive/2009/12/30/what-is-a-dump-and-how-do-i-create-one.aspx)

2) To remedy issue #1, I tried using procdump application to obtain my dump after it crashed, but that was also useless, and pointing to code somewhere inside Run(). The fix turned out to be using procdump to launch the application and write the crash dump the moment it crashes. That finally fixed the problem, and opening the crashdump brought me straight to the offending line of code. The procdump command I used was:

procdump -e -ma -x dump.dmp "C:\Program Files(86)\My Company\MyApp.exe"
Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top