locked
AppDomain.CurrentDomain.UnhandledException

    Question

  • I have an ActiveX control that periodically raises an exception that's trappable under AppDomain.CurrentDomain.UnhandledException.

    I use the following to wire up the event (in my constructor):

          System.AppDomain.CurrentDomain.UnhandledException += new System.UnhandledExceptionEventHandler(this.AppDomain_CurrentDomain_UnhandledExceptionHandler);
    

    My handler works just great!

        private void AppDomain_CurrentDomain_UnhandledExceptionHandler(System.Object sender, System.UnhandledExceptionEventArgs e)
        {
          Program.MsgBox("AppDomain UnhandledException caught");
        } //private void AppDomain_CurrentDomain_UnhandledExceptionHandler(System.Object sender, System.UnhandledExceptionEventArgs e)
    

    ... except that after notifying me of the exception, the application goes ahead and crashes.  I've examined the UnhandledExceptionEventArgs object and there isn't any Handled or Suppression option available.

    So how do I handle such an exception without crashing my application?


    It never hurts to try. In a worst case scenario, you'll learn from it.
    Thursday, April 14, 2011 7:52 PM

Answers

  • You can't - AppDomain.UnhandledException is designed specifically to allow " the application to log information about the exception before the system default handler reports the exception to the user and terminates the application. If sufficient information about the state of the application is available, other actions may be undertaken — such as saving program data for later recovery. Caution is advised, because program data can become corrupted when exceptions are not handled."

     

    It isn't intended to be used to restore program flow - just to let you log the error and potentially save data for future runs of the application.  At the point the AppDomain gets the exception, your process will end - this is not avoidable.

     

    You need to handle the exception directly in the class containing the control.

     


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    Thursday, April 14, 2011 8:11 PM
    Moderator
  • Well Andrew from what I have researched so far, it seems that creating the event handler for this exception is merely giving you the opportunity to cleanly exit yourself, rather than giving you the opportunity to stop it. I would suggest looking closely at the exception and creating a try catch finally in there.
    Thursday, April 14, 2011 8:19 PM
  • This did the trick.  Routes all exceptions of any type to the application thread exception handler.  Whew.
    System.Windows.Forms.Application.SetUnhandledExceptionMode(System.Windows.Forms.UnhandledExceptionMode.CatchException);<br/>
    

    It never hurts to try. In a worst case scenario, you'll learn from it.
    Thursday, April 14, 2011 10:00 PM

All replies

  • Yep.  It's readonly.

    It never hurts to try. In a worst case scenario, you'll learn from it.
    Thursday, April 14, 2011 8:00 PM
  • lol, yeah sorry about that post. I tried it right afterwards and saw that myself..
    Thursday, April 14, 2011 8:01 PM
  • You can't - AppDomain.UnhandledException is designed specifically to allow " the application to log information about the exception before the system default handler reports the exception to the user and terminates the application. If sufficient information about the state of the application is available, other actions may be undertaken — such as saving program data for later recovery. Caution is advised, because program data can become corrupted when exceptions are not handled."

     

    It isn't intended to be used to restore program flow - just to let you log the error and potentially save data for future runs of the application.  At the point the AppDomain gets the exception, your process will end - this is not avoidable.

     

    You need to handle the exception directly in the class containing the control.

     


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    Thursday, April 14, 2011 8:11 PM
    Moderator
  • Well Andrew from what I have researched so far, it seems that creating the event handler for this exception is merely giving you the opportunity to cleanly exit yourself, rather than giving you the opportunity to stop it. I would suggest looking closely at the exception and creating a try catch finally in there.
    Thursday, April 14, 2011 8:19 PM
  • You need to handle the exception directly in the class containing the control.

    Not an option.  It's the ActiveX component for Acrobat Reader.  If a document is loaded and the user presses tab while the component has focus, it generates the exception. Looks like they've known about it since version 6 or so and keep promising to fix it and don't.  Yay outsourcing!

    I've considered wrapping the ActiveX component in its own thread which can terminate when its background thread pukes on it, then just restart a new thread/instance... sort of suspecting that's going to be an awful lot of wasted time, since it looks like this problem is going to creep up and up and up the thread tree until it kills the application, no matter how deep I bury it.


    It never hurts to try. In a worst case scenario, you'll learn from it.
    Thursday, April 14, 2011 8:26 PM
  • I've considered wrapping the ActiveX component in its own thread which can terminate when its background thread pukes on it, then just restart a new thread/instance... sort of suspecting that's going to be an awful lot of wasted time, since it looks like this problem is going to creep up and up and up the thread tree until it kills the application, no matter how deep I bury it.

    The only thing that ~might~ work here, instead, would be to host this in its own AppDomain - but that's adding a lot of complexity to handle...

     

     


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    Thursday, April 14, 2011 8:39 PM
    Moderator
  • A separate AppDomain is definitely a new one on me, but I'm game.

          System.AppDomain AcrobatDomain = System.AppDomain.CreateDomain("AcrobatDomain");
          AcrobatDomain.CreateComInstanceFrom("AxInterop.AcroPDFLib.dll", "AxAcroPDFLib.AxAcroPDF");
          
    
    This seems to work; throws no exceptions at runtime.  So what do I do next in order to get the ComInstance displayed in my WinForm?


    It never hurts to try. In a worst case scenario, you'll learn from it.
    Thursday, April 14, 2011 9:05 PM
  • You'd have to display it in a separate form - I don't think there is a way to host a control in a different AppDomain in your form, at least not without doing something pretty crazy.  You could try P/Invoke with SetParent to reparent the Form inside of your Form...

     


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    Thursday, April 14, 2011 9:24 PM
    Moderator
  • This did the trick.  Routes all exceptions of any type to the application thread exception handler.  Whew.
    System.Windows.Forms.Application.SetUnhandledExceptionMode(System.Windows.Forms.UnhandledExceptionMode.CatchException);<br/>
    

    It never hurts to try. In a worst case scenario, you'll learn from it.
    Thursday, April 14, 2011 10:00 PM
  • Any update? Has your question been resolved?

    Best Regards,


    Larcolais Gong[MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, April 15, 2011 4:14 PM
  • Any update? Has your question been resolved?

    Best Regards,


    Larcolais Gong[MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.


    Yes?  About 18 hours before your post, I discovered that I could use the following line of code to route ALL exceptions to my specified event handler, disregarding default actions (in other words I can route exceptions to my handler and then I can choose whether the exception is fatal or not).  I did post.

     

    System.Windows.Forms.Application.SetUnhandledExceptionMode(System.Windows.Forms.UnhandledExceptionMode.CatchException);

    It never hurts to try. In a worst case scenario, you'll learn from it.
    Friday, April 15, 2011 6:18 PM