Search code examples
c#.netbitmapbackgroundworkergdi+

Pointing out Location of Error from StackTrace-Multiple Threads

I have the following code to catch unhandled Exceptions withing the Program.cs file in a winforms Applications

 private static void OnGuiUnhandedException(object sender, System.Threading.ThreadExceptionEventArgs e)
        {             
            MessageBox.Show(e.Exception.Message);
            MessageBox.Show(e.Exception.StackTrace.ToString());
            MessageBox.Show(e.Exception.TargetSite.ToString());               
            Application.Exit();
        }

I'm working with images.I keep getting this Exception

Object is Currently in use elsewhere

The applications uses 2 background workers at the same time. I have been trying to point out the exact location/line number from the error.

From the stacktrace this is what i get

enter image description here

How can i locate the exact location of the error? so that i can take appropriate measures to correct this issue.

Solution

  • You need to use Windows debugging tools, like Adplus,Windbg or a MemoScope.Net, a relatively new Graphical tool which internally use clrmd. Idea remains, issues like Crash, Hang, which are systems issues, especially in multi user / multi thread environment occurring due to synchronization, data structure / memory corruption, need to be debugged by creating a snapshot / dump at the run-time, which needs to be analyzed using the correct Pdb files (Program Debug Database), so that thread stacks can be reviewed, where exception / deadlock is happening and thus a corrective measure can be invoked.

    Just by looking at the information provided by you, it is very difficult to guess, what might have gone wrong, but my guess is as you have multiple background workers doing the processing, therefore the access to the resource need to be Synchronized, using a lock or similar construct, thus more than one thread doesn't tries to access it at same time.

    Another question remains, why Background worker in current day, why not Async Await, that would be much cleaner implementation and would not have the challenge of multiple threads, as it doesn't dispatch the call on a separate thread.