Question

Background

In my utilities library (Shd.dll) I have a class called AsyncOperation. To put it simply, it’s a base class for types that encapsulate a potentially long running operation, executes it on a background thread, and it supports pause/resume, cancellation and progress reporting. (It’s like a BackgroundWorker, just knows more things.)

In the user code you can use it like this:

class MyOperation : AsyncOperation
{
    public MyOperation() : base(null, AsyncOperationOptions.Cancelable | AsyncOperationOptions.Pausable) {}

    protected override void RunOperation(AsyncOperationState operationState, object userState)
    {
         ...
         operationState.ThrowIfCancelled();
    }
}

 var op = new MyOperation();
 op.Start();
 ...
 op.Cancel();

operationState.ThrowIfCancelled() does exactly what its name suggests: if Cancel() was called earlier by another thread, it throws an internal exception (AsyncOperationCancelException), which is then handled by the AsyncOperation type, like this:

private void _DoExecute(object state)
{
    // note that this method is already executed on the background thread
    ...
    try
    {
        operationDelegate.DynamicInvoke(args); // this is where RunOperation() is called
    }
    catch(System.Reflection.TargetInvocationException tiex)
    {
        Exception inner = tiex.InnerException;
        var cancelException = inner as AsyncOperationCancelException;
        if(cancelException != null)
        {
             // the operation was cancelled
             ...
        }
        else
        {
            // the operation faulted
            ...
        }
        ...
    }
    ...
}

This works perfectly. Or so I thought for the past year, while I was using this in numerous scenarios.

The actual problem

I’m building a class that uses System.Net.WebClient to upload potentially large number of files via FTP. This class is built using the AsyncOperation base class as described above.

For accurate progress reports, I use WebClient.UploadFileAsync(), which complicates the code, but the relevant parts look like this:

private ManualResetEventSlim completedEvent = new ManualResetEventSlim(false);

private void WebClient_UploadProgressChanged(object sender, UploadProgressChangedEventArgs e)
{
    ...
    if (OperationState.IsCancellationRequested)
    {
        _GetCurrentWebClient().CancelAsync();
    }
}

private void WebClient_UploadFileCompleted(object sender, UploadFileCompletedEventArgs e)
{
    ...
    _UploadNextFile();
}

private void _UploadNextFile()
{
    if (OperationState.IsCancellationRequested || ...)
    {
        this.completedEvent.Set();
        return;
    }
    ...
}

protected override void RunOperation(AsyncOperationState operationState, object userState)
{
    ...
    _UploadNextFile();
    this.completedEvent.Wait();

    operationState.ThrowIfCancelled(); // crash
    ...
}

As you can see, I marked the line where the crash occurs. What exactly happens is that when execution hits that line (I put a break point right over it, so I know this is the exact line), Visual Studio 2010 freezes for about 15 seconds, and then the next thing I see is the source code of AsyncOperationState.ThrowIfCancelled():

public void ThrowIfCancelled()
{
    if(IsCancellationRequested)
    {
        throw new AsyncOperationCancelException();
    }
} // this is the line the debugger highlights: "An exception of type AsyncOperationCancelException' occured in Shd.dll but was unhandled by user code."

I tried putting breakpoints to where the exception should have been caught, but the execution never reaches that catch {} block.

The other weird this is that at the end it also writes the following: “Function evaluation disabled because a previous function evaluation timed out.” I Googled this problem, and tried everything that was suggested (disabled implicit property evaluation, removed all breakpoints), but nothing helped so far.

Here are two screenshots that illustrate the problem:
http://dl.dropbox.com/u/17147594/vsd1.png
http://dl.dropbox.com/u/17147594/vsd2.png

I’m using .NET 4.0. Any help would be very much appreciated.

Answer 1

When the Visual Studio debugger is attached to an application, it gets notified whenever an exception is thrown, before the running code gets the chance to handle it. This is called a first-chance exception, and VS can be configured to break execution when a certain exception type is thrown.

You can specify debugger behavior for each exception type separately using the Exceptions window (Debug menu). By default, all exceptions have the “User-unhandled” checkbox checked, meaning that only unhandled exceptions will break execution. Setting the “Thrown” checkbox for a certain exception type forces VS to break execution even if the exception will be handled, but only for that exception type (not for derived types). If a handler exists, once you resume execution (by pressing F5), the exception will be caught normally.

I would guess that your custom exception was added to the list of exceptions in the Exceptions window (which you can check by using the Find button inside the window).

[Edit]

According to my tests, it also happens when DynamicInvoke is used in .NET 4, regardless of the Exceptions window setting. Yesterday I was using VS2008 and I couldn’t reproduce it, but it does seem like odd behavior now.

This is the test I tried (sorry for the brief formatting, but it’s fairly simple):

Action<int> a = i => { throw new ArgumentException(); };

// When the following code is executed, VS2010 debugger
// will break on the `ArgumentException` above 
// but ONLY if the target is .NET 4 (3.5 and lower don't break)
try { a.DynamicInvoke(5); }
catch (Exception ex)
{ }

// this doesn't break
try { a.Invoke(5); }
catch (Exception ex)
{ }

// neither does this
try { a(5); }
catch (Exception ex)
{ }

My only guess is that exception handling done inside InvokeMethodFast (which is an InternalCall method) has somehow changed. DynamicInvoke code has changed between versions 4 and prior, but there is nothing which would indicate why VS2010 debugger is unable to see that there is an exception handler inside that method call.