I cant seem to make heads or tails of how I am supposed to properly handle unexpected exceptions.
Consider the following application:
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new SomeForm());
}
class SomeForm : Form
{
public SomeForm()
{
Button btn = new Button();
btn.Text = "Click ME";
btn.Location = new System.Drawing.Point(20, 20);
btn.Click += new EventHandler(btn_Click);
Controls.Add(btn);
}
void btn_Click(object sender, EventArgs e)
{
throw new Exception("This is an Exception");
}
}
If I run this application and click the button I get an unhandled exception as expected. At first I tried surrounding the Application.Run with a try catch block like so:
try { Application.Run(new SomeForm()); }
catch { MessageBox.Show("Exception caught in try catch"); }
At first this seems to work, until I ran the application outside of the Debugger. When you run the application outside of the Debugger, the exception is reported as an unhandled error. After doing some reading I discovered I should be looking at the Application.ThreadException event. So I do the following:
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
try { Application.Run(new SomeForm()); }
catch { MessageBox.Show("Exception caught in try catch"); }
}
static void Application_ThreadException(object sender, System.Threading.ThreadExceptionEventArgs e)
{
MessageBox.Show("Exception caught in event");
}
Now when I run my application outside of the debugger the exception is handled and the MessageBox indicates it was caught in the event handler. Then I go back into the debugger and run it. Now the Debugger kicks it up as an unhandled exception even though I have surrounded it in a try catch AND I am tied onto the Application.ThreadException event. If I do not tie up the to Application.ThreadException event the exception is caught correctly by the try catch block.
Now to the questions:
What the heck is going on here?
Is there a way that I can catch/handle all exceptions in my application that works both in the debugger and outside of the debugger?
Am I just doing the completely wrong thing here?
You can handle them using AppDomain.CurrentDomain.UnhandledException and Application.ThreadException, look for more.
What's the difference between Application.ThreadException and AppDomain.CurrentDomain.UnhandledException?
The debugger considers exceptions that propagate to Application_ThreadException to be unhandled exceptions, since that event handler is used as a final location to log and terminate gracefully. This allows you to stop at the point of the exception when running the debugger, which is often very helpful.
It's not possible to handle all exceptions in one global place because there is not enough context to know how to actually handle them. You can catch all exceptions (even the unhandled ones) using Application_ThreadException (and AppDomain.UnhandledException for exceptions on other threads), but the next thing you should do in that case is shut down your application.
You should handle exceptions in each method separately, based on the information you have and the knowledge of the types of exceptions that can occur. Exceptions you don't know how to handle should not be caught and will percolate to the 'global' event handlers, which should log the details and politely shut down the application.
Related
After reading this MSDN page, I've created a global exception handler in my .net class library, for logging purposes, which looks like this:
static void OnException(object sender, UnhandledExceptionEventArgs args)
{
Exception ex = (Exception)args.ExceptionObject;
Logging.LogException(ex);
}
But then if I throw new UnauthorizedAccessException() or throw new Exception() from a method, this does not catch it at all.
The MSDN page says:
UnhandledExceptionEventArgs provides access to the exception object
and a flag indicating whether the common language runtime is
terminating. The UnhandledExceptionEventArgs is one of the parameters
passed into UnhandledExceptionEventHandler for the
AppDomain.UnhandledException event
I believe what I'm doing falls under the AppDomain (and not ThreadException)? What am I doing wrong here?
PS. I'm trying to avoid a try-catch block, since apparently it's bad practice. This class library is called from a windows service which runs periodically so I'd rather not let it 'crash' to avoid memory leaks due to unforeseen exceptions and would prefer to monitor the event logs regularly.
You will need to install the exception handler in the current app domain in order for it to fire:
AppDomain.CurrentDomain.UnhandledException += OnException;
Otherwise its just a method declaration that will never be called.
You mention that you are trying to avoid a try catch, but inside your handler, that wouldn't be a bad idea:
static void OnException(object sender, UnhandledExceptionEventArgs args)
{
try
{
Exception ex = (Exception)args.ExceptionObject;
Logging.LogException(ex);
}
catch
{
// do nothing to silently swallow error, or try something else...
}
}
...Because you don't want to explode in your error handler. Either swallow if stability is of primary importance, or try a secondary (more basic) logging method to insure that no exception falls through the cracks.
Normally, swallowing an exception silently is a poor practice, but this is inside an error handling block where failure means crashing an app.
I am investigating some crashes in my application caused by a Win32 exception, and I have narrowed it down that it must be occurring in the threadpool which is taking care of the EventLog.EntryWrittenEventHandler event handler in my application. I set this up like this:
// Create the event log monitor
eventLog.Log = "Application";
eventLog.EnableRaisingEvents = true;
eventLog.EntryWritten += new EntryWrittenEventHandler(EventLogMonitor);
EventLogMonitor is the handler for my event. I am wondering does anybody have any ideas as to where I could find out whats causing this exception. It seems that to listen for events a ThreadPoolWaitOrTimerCallback is being set up, which wouldn't have any of my code on it, and if the exception is occurring on this I just cant see how to deal with this problem. Any help is really appreciated!!
Here is the output of !clrstack in WinDBG:
0:008> !clrstack
OS Thread Id: 0x106c (8)
ESP EIP
049df1c8 7756f871 [HelperMethodFrame: 049df1c8]
049df26c 73ce6fa0 System.Diagnostics.EventLog.get_OldestEntryNumber()
049df27c 73bf24ed System.Diagnostics.EventLog.CompletionCallback(System.Object)
049df2c4 73bf0fe4 System.Diagnostics.EventLog.StaticCompletionCallback(System.Object, Boolean)
049df2f4 744fc3b8 System.Threading._ThreadPoolWaitOrTimerCallback.WaitOrTimerCallback_Context(System.Object, Boolean)
049df300 744fc373 System.Threading._ThreadPoolWaitOrTimerCallback.WaitOrTimerCallback_Context_f(System.Object)
049df304 7400027f System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
049df31c 744fc477 System.Threading._ThreadPoolWaitOrTimerCallback.PerformWaitOrTimerCallback(System.Object, Boolean)
049df4ac 74991b5c [GCFrame: 049df4ac]
In case it helps, my application is just checking the event ID of every entry written to the event log, and if it matches one of a certain set of ID's then I log it. The crashes happen quiet rarely, and the exception is a System.ComponentModel.Win32 exception with message 'Access is denied'. That sounds like it could be a permissions issue but why would it work ok for a certain period and then suddenly crash with this.
If I understand you correctly (it would help if you pass the stacktrace that leads you to the conclusion that the exception is happening inside a threadpool thread), then just wrap your code of EventLogMonitor in a try/catch block.
Example:
void EventLogHandler(object sender, EventArgs args)
{
try
{
// Your original code.
}
catch (Exception ex)
{
// Log or Write "ex" to the console. Set a breakpoint, whatever.
throw;
}
}
UPDATE: after your update it looks as if the exception is indeed not raised from inside your handler, but before it is even called inside the EventLog class.
You could try registering a handler with the AppDomain.UnhandledException event and do your logging/handling in there. Note that this will not allow you to suppress or "change" or wrap the exception, but merely to log it somewhere for diagnostic purposes.
If you just want to inspect the exception once (or on occasion), you should try using the SOS-extension's !PrintException command in WinDBG.
UPDATE 2: after further investigation I find it rather strange that the exception bubbles up all. Your stacktrace suggests you're using .NET 3.5 (or earlier, but not 4.) and looking at the EventLog class in Reflector you can see that the whole handling of the EventWrittenHandler, including the preamble code that seems to cause the exception, is wrapped in one big "try/catch(Exception)/catch" block. Funny.
Subscribe to Application.ThreadException in your Program.cs as follows to be able to catch the exceptions that are not in main thread.
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.ThreadException += Application_ThreadException;
try
{
Application.Run(new MainForm());
}
catch (Exception e)
{
HandleException(e);
}
}
static void Application_ThreadException(object sender, System.Threading.ThreadExceptionEventArgs e)
{
HandleException(e.Exception);
}
If you can, use Tasks in System.Threading.Tasks.
Try, where action is performing what you want.
ThreadPool.QueueUserWorkItem(state =>
{
try
{
action();
}
catch (Exception ex)
{
OnException(ex);
}
});
Not sure what kind of Application this is, so in a general case, if you're having no luck, try hooking into the AppDomain in which the code is running. If you don't have multiple domains, you can try:
AppDomain.CurrentDomain.FirstChanceException += Handler
or
AppDomain.CurrentDomain.UnhandledException += Handler
This is getting extremely irritating. Right now I have a winforms application, and things were not working right, but no exceptions were being thrown as far as I could tell. After stepping through almost all pieces of relevant code, it turns out that an exception was being thrown at the start of my application.
Long story short, in WinForms, being as awesome as it is, if an exception occurs the WinForms library ignores it. No "an unhandled exception has occurred" JIT message is thrown, it just stops processing the current event and goes back to the GUI.
This is causing random bugs, because code to load data isn't being called due to the exception occurring prior to this data being loaded.
To see this in action I created a brand new WinForms application, and entered the following code:
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender, EventArgs e)
{
string blah = null;
blah.Trim();
}
}
Press F5 and the form loads without any errors showing, even though a null reference is being thrown.
I then tried to go to my Program.cs main method and add Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException); to it. Still my form loads without causing any errors to be thrown.
Even though I know that I can tell VS to break on all exceptions, I find this situation really bad. It causes really wierd issues that are hard to debug in production, and as this is an internal tool I really want to have it so it actually errors out when an exception occurs, and not silently disregards it.
Does anyone know how to do this?
Update: Just to update on things I have learned from the comments.
This does appear to be a 64-bit issue with windows, as I learned from this question which I did not see before posting. In that question it pointed to a Microsoft bug report about this, which had this to say:
Hello,
This bug was closed as "External" because this behavior results from how x64 version of Windows handle exceptions. When a user mode exception crosses a kernel transition, x64 versions of Windows do not allow the exception to propagate. Therefore attached debuggers are unaware of the fact that an exception occured resulting in the debugger failing to break on the unhandled exception.
Unfortunately where is nothing that the Visual Studo team can do to address this, it is the result of operating system design. All feedback regarding this issue should be addressed to the Windows team; however the Windows team considers this to be the "correct" operating system design, and considers the x86 behavior to be "incorrect".
Best Regards,
Visual Studio Debugger
That being said, builds not run through visual studio (or using Ctrl+F5 to run) does seem to show the JIT exception message box EXCEPT if you have the following code in your Program.cs:
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException);
That code will cause windows to ignore the exception.
However, if you (instead) subscribe to the Application.ThreadException event, not only will your exceptions be caught, visual studio's debugger will break on unhandled exceptions!
In your Program.cs' Main function you should also ensure that you've wrapped your call to open the form in a try/catch. Additionally use the AppDomain.UnhandledException to catch exceptions. We also add Application.ThreadException too.
I believe the following will give you hooks into all the exceptions that can be thrown...
static void Main()
{
try
{
System.Windows.Forms.Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);
System.Windows.Forms.Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(OnGuiUnhandedException);
AppDomain.CurrentDomain.UnhandledException += OnUnhandledException;
var form = new MainForm();
form.ShowDialog();
}
catch (Exception e)
{
HandleUnhandledException(e);
}
finally
{
// Do stuff
}
}
private static void HandleUnhandledException(Object o)
{
// TODO: Log it!
Exception e = o as Exception;
if (e != null)
{
}
}
private static void OnUnhandledException(Object sender, UnhandledExceptionEventArgs e)
{
HandleUnhandledException(e.ExceptionObject);
}
private static void OnGuiUnhandedException(object sender, System.Threading.ThreadExceptionEventArgs e)
{
HandleUnhandledException(e.Exception);
}
Try the following.
Handle exceptions in your main application entry point.
Also, manage unhandled thread exceptions using a ThreadExceptionEventHandler
This is the code snippet:
[STAThread]
public static void Main(string[] args)
{
try
{
Application.ThreadException += new ThreadExceptionEventHandler(Application_ThreadException);
//your program entry point
}
catch (Exception ex)
{
//manage also these exceptions
}
}
private void Application_ThreadException(object sender, ThreadExceptionEventArgs e)
{
ProcessException(e.Exception);
}
An easy fix is not to run under the debugger.
The debugger is masking the exception for some reason. If you run your app normally (Ctrl+F5), you'll get the usual "Unhandled exception has occurred in your application... Continue/Quit?" dialog.
Having experienced this often and identified the issue regarding 64 bit OS and the Form.Load event, I always just make a point of doing all my start up functions in the Form.Shown event. For all practical purposes this is the same thing (aside from a few rare, exceptional circumstances), and the JIT message is produced in the Shown event.
I tried to write a little crash reporter for uncatched expetions. This works perfectly when starting my App in VS.
But as soon as I try to start the .exe it only shows me the standard "There is an uncaught expetion"-thingy from windows.
And no it's not the crashreporter which crashes.
This is my code in the Program.cs
try
{
Application.Run(new TestServer());
}
catch (Exception e)
{
Application.Run(new CrashReporter(e.StackTrace.ToString()));
}
}
This is because you use a debugger. Winforms detects this and disables the event handler for Application.ThreadException. That's important, it lets you debug exceptions. To get your catch clause to work without a debugger, you'll have to add this statement to your Main() method, before the Run() call:
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException);
It now does make more sense to write an event handler for AppDomain.Current.UnhandledException instead, you'll also get notified about unhandled exceptions in worker threads.
Instead of this you can handle following event (which is the preferred way of handling unhandled application exceptions):
AppDomain.CurrentDomain.UnhandledException += (sender, e) =>
{
Application.Run(new CrashReporter(e.StackTrace.ToString()));
}
Application.Run(new TestServer());
Are you running on a 64 bit OS? This sounds like the problem Hans Passant answered here.
Debugging can swallow errors on Form construction and Forms_Load in 64 bit CLR...
Are you sure this thing works? I mean, did this strategy work for you previously?
I use (and suggested way) this way to catch the unhandled exceptions globally:
AppDomain.CurrentDomain.UnhandledException +=
new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
//then start the main form...
Application.Run(new TestServer());
Here is the documentation
http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx
CrashReporter is causing it. An uncaught exception in a catch statement will cause an uncaught exception. You need another try/catch in your catch and another fall back.
I have an app, and after about 20 minutes of idle time the program just crashes. ("Windows has encountered an error and needs to close...")
I have no idea why this is happening. What is the best way to go about debugging something like this?
Generally crashes in .Net applications are caused by an unhandled exception - i.e. an exception in a thread in that application that was not caught in a try-catch block of some sort:
try
{
// Some code that may throw an exception
}
catch (Exception ex)
{
Console.WriteLine(ex.ToString());
}
A good first place to check for information about this exception is the application event log, often however you will find that the .Net framework posts only minimal information about the crash - if this is the case then you need to catch and handle the exception yourself, recording enough information to allow you to diagnose the error.
Typically there are two way that you might do this:
1. Ensure that the code for each thread of your application is contained in a try-catch block.
This is the easiest method - unless your application has multiple user threads (you will know if it has), this simply requires that you place a try-catch block around the entry point of your application, for example in a Windows Forms application:
// Probably found somewhere in Program.cs
[STAThread]
static void Main()
{
try
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new Form1());
}
catch (Exception ex)
{
MessageBox.Show(ex.ToString());
}
}
If you are working on a console application then you will need to use something other than MessageBox (see the first example).
If you spawn multiple threads then the entry point method for each thread should also catch all exceptions in a similar way.
2. Handle the UnhandledException event of the current App Domain
This event will be fired whenever any thread throws an unhandled exception in the current App Domain. Generally speaking it is best to use the first method instead, however this event is still useful in some situations.
Example:
static void Main()
{
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
// The rest of your application
}
static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
Console.WriteLine(e.ExceptionObject.ToString());
}
Of course it is worth pointing out that the error still might not be caught by either of the above two methods (which is possible if the error is caused by a native module loaded in the same process), however this should probably do the trick.
Finally - Good luck!