Unhandled exception of type System.Exception occurred in FM.dll

Question

I'm using WebSync in a .NET application where a client is making calls to connect, subscribe, etc to WebSync. Somewhere along the execution of the code (It's a big app), I get the gray box popup saying the above error message. Because this is a big app, how can I find where in the application this is occurring? The problem is that this application has a lot of threads.

Does this message mean there is a problem in FM.dll (WebSync) or does it mean that I'm missing something in my code that should catch this exception. If the latter, how do I find where in my code this may occur?

Thanks!

Here is the Call Stack to my error. How can I tell if this is an error on my part or if the problem is inside FM.dll (WebSync)?

FM.dll!FM.AsyncException.AsyncThrow.AnonymousMethod__0(object unused) + 0x47 bytes
mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x285 bytes mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x9 bytes
mscorlib.dll!System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem() + 0x6f bytes mscorlib.dll!System.Threading.ThreadPoolWorkQueue.Dispatch() + 0x1ea bytes
[Native to Managed Transition]
[Appdomain Transition]
[Native to Managed Transition]

Answer 1

In FM libraries, AsyncException.AsyncThrow is used when an exception is thrown in an async callback. Try wrapping your FM callback code in try/catch blocks to catch exceptions, e.g.:

client.Connect(new ConnectArgs
{
    OnSuccess = (e) =>
    {
        try
        {
            // your code
        }
        catch (Exception ex)
        {
            // handle exception
        }
    }
});

If you don't wrap your callback code in a try/catch block, then the FM library will push the exception to a thread where it will be fail loudly rather than swallow/hide it.

Answer 2

If you have 'Break on All Exceptions' turned on then once you start the debugger, when the exception is thrown, you'll be able to see and navigate the stack trace. This should give you an idea of the path the code is on leading up to the exception. You can also interrogate the exception to check to see if the InnerException property has been set. From that information you should be able to determine what is causing the issue. If not post more details from the information you gather and you can get more help.

Instruction for setting up Visual Studio to break on all exceptions: http://msdn.microsoft.com/en-us/library/d14azbfh.aspx