tags:

views:

117

answers:

3

I have an application that sporadically throws this exception:

System.ObjectDisposedException: Cannot access a disposed object.
Object name: "Panel". 
   bei System.Windows.Forms.Control.CreateHandle() 
   bei System.Windows.Forms.Control.get_Handle() 
   bei System.Windows.Forms.ContainerControl.FocusActiveControlInternal() 
   bei System.Windows.Forms.Form.set_Active(Boolean value) 
   bei System.Windows.Forms.Form.WmActivate(Message& m) 
   bei System.Windows.Forms.Form.WndProc(Message& m) 
   bei System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) 
   bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) 
   bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Is there a way to suppress this exception ideally without touching the code? I am thinking about some registry magic or esoteric .NET configs.

Furthermore I am of course also interested in ways to catch this exception. There seems to be no hook for me to catch this exception... And of course it is not reproducible...

+3  A: 

The runtime is trying to tell you something. Don't ignore it! Catching and ignoring the exception does not make the problem go away.

The specific exception tells you that you're trying to use a Panel after it has been disposed. So you basically have two options here: 1) Don't expose until you're finished using it. 2) Don't use it after it has been disposed.

EDIT: To help you troubleshoot the problem, you could set up ADPlus to create dump files for that specific exception. That could give you some insight as to why this happens. John Robbins has a Bugslayer article on how to do that. Please see http://msdn.microsoft.com/en-us/magazine/cc163530.aspx.

Brian Rasmussen
I am aware of that ;) Ideally I would handle this exception gracefully in the code. But (a) at the moment I don't have an idea how to approach this issue and (b) a quick fix would give me more time to investigate.
tatt
Okay, sorry if I was stating the obvious then. However, there's a risk that the quick fix will just cause new errors. My suggestion would be to take the time to identify the source of the prob
Brian Rasmussen
A: 

About catching the exception; I'm guessing there is no global exception handling in that application yet?

In your Program.cs:

static void Main()
{
    Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
    AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);

    Application.Run(new MainForm());
}

static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
    // Handle exception
    Application.Exit();
}

static void Application_ThreadException(object sender, System.Threading.ThreadExceptionEventArgs e)
{
    // Handle exception
    Application.Exit();
}

Adding this, and gracefully handling the exception would be a good thing for the user. If you add some additional logging, it might even help you eliminate the cause for the exception. Specifically targeting the ObjectDisposedException can be done by checking the exception type in the above handlers.

Cloud
Thanks. This is what I was looking for.
tatt
Hmmm. Ok. Now I have a global exception handler, but it seems that every `UnhandledExceptionEventArgs` I get the `IsTerminating` property is true. Not exactly what I expected.
tatt
Is it not? The system is planning to terminate the application, because the exception goes unhandled and therefore the application state cannot be guaranteed to be correct.You could of course choose to not exit the application in these two global handlers (by omitting Application.Exit();) but what good will that do?In the end the only moment you can continue the application is when you successfully handled the exception.
Cloud
I added the `Application.Exit();` to the sample code, because it should be there, imho.
Cloud
A: 

"Is there a way to fix the pain in my left leg that I get every time I shoot myself in the foot? Perhaps taking copious amounts of paracetamol or similar?"

The answer here is not to fix the pain, it's avoiding shooting yourself in the foot.

In this case, there's code accessing a panel that is disposed. This code must be fixed, the answer is not to suppress the exception because you really do have a bug in your code. It's not the runtime that is in fault here.

Now, I see from comments that you want a "quick fix" to get back to work, that kind of attitude is not going to help you for long because, as you see, every answer and possible solution brings new questions.

So instead of spending time trying to silence the runtime telling you that you have a bug, stop doing that and fix the bug.

Lasse V. Karlsen