How to walk the .NET try/catch chain to decide to generate a minidump

We've hit a snag mixing Tasks with our top-level crash handler and are trying to find a workaround. I'm hoping someone has some ideas.

Our tools have a top-level crash handler (from the AppDomain's UnhandledException event) that we use to file bug reports with minidumps. It works wonderfully. Unfortunately, Tasks throw a wrench in this.

We just started using 4.0 Tasks and discovered that internally in the Task action execution code, there is a try/catch which grabs the exception and stores it for passing down the task chain. Unfortunately, the existence of the catch (Exception) unwinds the stack and when we create the minidump the call site is lost. That means we have none of the local variables at the time of the crash, or they have been collected, etc.

Exception filters seem to be the right tool for this job. We could wrap some Task action code in a filter via an extension method, and on an exception getting thrown call our crash handler code to report the bug with the minidump. However, we don't want to do this on every exception, because there may be a try-catch in our own code that is ignoring specific exceptions. We only want to do the crash report if the catch in Task was going to handle it.

Is there any way to walk up the chain of try/catch handlers? I think if I could do this, I could walk upwards looking for catches until hitting Task, and then firing the crash handler if true.

(This seems like a long shot but I figured I'd ask anyway.)

Or if anyone has any better ideas, I'd love to hear them!

UPDATE

I created a small sample program tha开发者_高级运维t demonstrates the problem. My apologies, I tried to make it as short as possible but it's still big. :/

In the below example, you can #define USETASK or #define USEWORKITEM (or none) to test out one of the three options.

In the non-async case and USEWORKITEM case, the minidump that is generated is built at the call site, exactly how we need. I can load it in VS and (after some browsing to find the right thread), I see that I have the snapshot taken at the call site. Awesome.

In the USETASK case, the snapshot gets taken from within the finalizer thread, which is cleaning up the Task. This is long after the exception has been thrown and so grabbing a minidump at this point is useless. I can do a Wait() on the task to make the exception get handled sooner, or I can access its Exception directly, or I can create the minidump from within a wrapper around TestCrash itself, but all of those still have the same problem: it's too late because the stack has been unwound to one catch or another.

Note that I deliberately put a try/catch in TestCrash to demonstrate how we want some exceptions to be processed normally, and others to be caught. The USEWORKITEM and non-async cases work exactly how we need. Tasks almost do it right! If I could somehow use an exception filter that lets me walk up the chain of try/catch (without actually unwinding) until I hit the catch inside of Task, I could do the necessary tests myself to see if I need to run the crash handler or not. Hence my original question.

Here's the sample.

using System;
using System.Diagnostics;
using System.IO;
using System.Net;
using System.Runtime.InteropServices;
using System.Threading;
using System.Threading.Tasks;
using System.Collections.Generic;
using System.Linq;

class Program
{
    static void Main()
    {
        AppDomain.CurrentDomain.UnhandledException += (_, __) =>
            {
                using (var stream = File.Create(@"c:\temp\test.dmp"))
                {
                    var process = Process.GetCurrentProcess();
                    MiniDumpWriteDump(
                        process.Handle,
                        process.Id,
                        stream.SafeFileHandle.DangerousGetHandle(),
                        MiniDumpType.MiniDumpWithFullMemory,
                        IntPtr.Zero,
                        IntPtr.Zero,
                        IntPtr.Zero);
                }
                Process.GetCurrentProcess().Kill();
            };
        TaskScheduler.UnobservedTaskException += (_, __) =>
            Debug.WriteLine("If this is called, the call site has already been lost!");

        // must be in separate func to permit collecting the task
        RunTest();

        GC.Collect();
        GC.WaitForPendingFinalizers();
    }

    static void RunTest()
    {

#if USETASK
        var t = new Task(TestCrash);
        t.RunSynchronously();
#elif USEWORKITEM
        var done = false;
        ThreadPool.QueueUserWorkItem(_ => { TestCrash(); done = true; });
        while (!done) { }
#else
        TestCrash();
#endif
    }

    static void TestCrash()
    {
        try
        {
            new WebClient().DownloadData("http://filenoexist");
        }
        catch (WebException)
        {
            Debug.WriteLine("Caught a WebException!");
        }
        throw new InvalidOperationException("test");
    }

    enum MiniDumpType
    {
        //...
        MiniDumpWithFullMemory = 0x00000002,
        //...
    }

    [DllImport("Dbghelp.dll")]
    static extern bool MiniDumpWriteDump(
        IntPtr hProcess,
        int processId,
        IntPtr hFile,
        MiniDumpType dumpType,
        IntPtr exceptionParam,
        IntPtr userStreamParam,
        IntPtr callbackParam);
}

It sounds like if you can wrap your top-level tasks in an exception filter (written in VB.NET?) you would be able to do what you want. Since your filter would run just before the Task's own exception filter, it would only get invoked if nothing else within your task handles the exception but before Task gets ahold of it.

Here's a working sample. Create a VB library project called ExceptionFilter with this in a VB file:

Imports System.IO
Imports System.Diagnostics
Imports System.Runtime.CompilerServices
Imports System.Runtime.InteropServices

Public Module ExceptionFilter
    Private Enum MINIDUMP_TYPE
        MiniDumpWithFullMemory = 2
    End Enum

    <DllImport("dbghelp.dll")>
    Private Function MiniDumpWriteDump(
            ByVal hProcess As IntPtr,
            ByVal ProcessId As Int32,
            ByVal hFile As IntPtr,
            ByVal DumpType As MINIDUMP_TYPE,
            ByVal ExceptionParam As IntPtr,
            ByVal UserStreamParam As IntPtr,
            ByVal CallackParam As IntPtr) As Boolean
    End Function

    Function FailFastFilter() As Boolean
        Dim proc = Process.GetCurrentProcess()
        Using stream As FileStream = File.Create("C:\temp\test.dmp")
            MiniDumpWriteDump(proc.Handle, proc.Id, stream.SafeFileHandle.DangerousGetHandle(),
                              MINIDUMP_TYPE.MiniDumpWithFullMemory, IntPtr.Zero, IntPtr.Zero, IntPtr.Zero)
        End Using
        proc.Kill()
        Return False
    End Function

    <Extension()>
    Public Function CrashFilter(ByVal task As Action) As Action
        Return Sub()
                   Try
                       task()
                   Catch ex As Exception When _
                       FailFastFilter()
                   End Try
               End Sub
    End Function
End Module

Then create a C# project and add a reference to ExceptionFilter. Here's the program I used:

using System;
using System.Diagnostics;
using System.Net;
using System.Threading.Tasks;
using ExceptionFilter;

class Program
{
    static void Main()
    {
        new Task(new Action(TestCrash).CrashFilter()).RunSynchronously();
    }

    static void TestCrash()
    {
        try
        {
            new WebClient().DownloadData("http://filenoexist");
        }
        catch (WebException)
        {
            Debug.WriteLine("Caught a WebException!");
        }
        throw new InvalidOperationException("test");
    }
}

I ran the C# program, opened up the DMP file, and checked out the call stack. The TestCrash function was on the stack (a few frames up) with throw new as the current line.

FYI, I think I would use Environment.FailFast() over your minidump/kill operation, but that might not work as well in your workflow.

Two possibilities spring to mind:

You can use the profiling API to act like a debugger and detect which catch block is about to catch an exception.

You can wrap each "critical task" Action/Func in your own try/catch wrapper.

Either one of these is quite a bit of work, though. To answer your specific question, I don't think that it's possible to walk the stack by hand.

EDIT: More on the profiling API approach: you may want to consider TypeMock, which was written for unit testing but exposes hooks that can be used at runtime (CThru is a library written over TypeMock's API, and there's at least one person who's used TypeMock at runtime). There's also an MSDN article about using the profiling API for code injection, but IMO TypeMock would save you money over doing it yourself.

It sounds like you want to create a minidump if a task throws an unhandled exception. Perhaps the stack is not yet unwound during the UnobservedTaskException event:

• TaskScheduler.UnobservedTaskException Event

I posted a similar question on the parallel computing forums. The workaround suggested there (by Stephen Toub) was to add an exception handler around the body of the Task that catches all exceptions and calls Environment.FailFast. (Or it could file a bug report with a minidump, etc.)

For example:

public static Action FailOnException(this Action original)
{
    return () => 
    { 
        try { original(); } 
        catch(Exception ex) { Environment.FailFast("Unhandled exception", ex); }
    };
}

Then instead of writing:

Task.Factory.StartNew(action);

you could write:

Task.Factory.StartNew(action.FailOnException());

Since this is guaranteed to be one layer below the default Task exception handler, you don't need to walk the exception handling chain, nor do you need to worry if some other code will handle it. (If the exception is caught and handled, it won't reach this handler.)

Alternatively, because (as Gabe notes in the comments) this will cause finally blocks to run, it should be possible (as suggested in your question, I believe) to add (using IL, VB.NET, or dynamic methods) an exception filter (in this extension method) that detects unhandled exceptions. Since you know that exceptions that were handled in a catch block won't reach this level, and since the only exception handler above you is that of Task itself, it should be fine to terminate the process at this point (and report an unhandled exception). The only exception (no pun intended) would be if you were anticipating the possibility of an exception and checking the Task.Exception property in the code that created the task. In that case, you wouldn't want to terminate the process early.