Develop Reference

Global exception handler with UnhandledExceptionEventArgs not working

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.

Non-terminating global exception handler in console applications

I have a console application written in C# code. Let's assume that it's the most simple application just like Hello World example:
class Program
{
static void Main(string[] args)
{
AppDomain.CurrentDomain.UnhandledException +=
CurrentDomain_UnhandledException;
int zero = 0;
int i = 10 / zero;
}
static void CurrentDomain_UnhandledException(
object sender, UnhandledExceptionEventArgs e)
{
Console.WriteLine("exception");
}
}
However, I want to handler the DevideByZero exception in the global exception handler, but without exiting the application through Environment.Exit().
Is it possible at all? How?
Note:
I've already seen these questions, but they're all terminating. The exception gets raised again and again.
.NET Global exception handler in console application
Global exception handling in c# (console application)

This is such a horribly bad idea that I wouldn't be surprised if it was purposely made very difficult or impossible to accomplish.
If the Unhandled exception handler ever gets called, your program is by definition in an unknown and most likely corrupt state. The only reasonable thing to do is to terminate the program as quickly as possible, after logging the error and maybe trying to save any critical data. Even that's a risk, because the error could have happened in the logger ... or in saving data during normal shutdown.
You want to catch the divide by 0 exception? And are you going to check where that exception occurred so that you only catch your own errors. Or is it okay if you blindly ignore when somebody else's code throws a divide by 0 exception?
And even if you can do that, what are you going to do when the exception occurs? It's not like you can just jump back to where you were and continue. The stack has been unwound and all context lost.
You do not want to do this. Really. Write your code so that it won't divide by 0. Or use try/catch. That's what it's for.

I think you can get it resolved using try catch block something like:-
try {
int zero = 0;
int i = 10 / zero;
}
catch (DivideByZeroException)
{
}

Try this (add a handler to 'Application.ThreadException' too):
static void Main(string[] args)
{
AppDomain.CurrentDomain.UnhandledException +=
CurrentDomain_UnhandledException;
Application.ThreadException +=
new System.Threading.ThreadExceptionEventHandler(
Application_ThreadException);
Application.SetUnhandledExceptionMode(
UnhandledExceptionMode.CatchException);
int zero = 0;
int i = 10 / zero;
}

NLog configured to automatically log all exceptions?

Is there a way to configure NLog to automatically log all exceptions my application can send? Currently I am going to all TRY/CATCH blocks and manually adding logging in the CATCH - but what if I miss some? And what if in the future someone else does
Is there a way to tell NLog to just always log all exceptions? Esspecially some that are not caught and could cause a popup?

As far as I know, there is no way to confineNLog to log all exceptions.
If all you want is to log unhandled exceptions, you could add an "UnhandledException Handler" to the AppDomain when initializing your application.
Note that under some circumstances it may not be possible to log the error (e.g. in case of an OutOfMemory exception or something terrible).
Note that the AppDomain also has a FirstChanceException event you can subscribe to, but this would mean that you get notified about every exception that occurs (and may be handled by the usercode) - in this are many.
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(AppDomain_CurrentDomain_UnhandledException);
static void AppDomain_CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
// use logger here to log the events exception object
// before the application quits
}
Note that this will only allow you to log exceptions that cause your application to crash - you cannot prevent it to crash (therefore the name: unhandled exception).
Another option would be to use Aspect Oriented Programming (AOP) - and introduce a Logging aspect after each method call, in case of an error. If your application uses a Layered architecture, this may be relatively easy to do (e.g. add an aspect to all calls of your business logic layer...).
You may find a framework like PostSharp or Spring.Net useful (usually their websites provide some easy examples for that).

For WebApi application you can do this in Global.asax.cs like that
protected void Application_Error()
{
Exception lastException = Server.GetLastError();
NLog.Logger logger = NLog.LogManager.GetCurrentClassLogger();
logger.Fatal(lastException);
}
MSDN resource

Jacek's answer is good for WebApi.
Here is an answer for console apps:
private static readonly NLog.Logger Logger = NLog.LogManager.GetCurrentClassLogger();
static void Main(string[] args)
{
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(AppDomain_CurrentDomain_UnhandledException);
Object o = SomeMethodToThrowError(); // Cause an exception
}
static void AppDomain_CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
// use logger here to log the events exception object
// before the application quits
Exception ex = (Exception)e.ExceptionObject;
Logger.Error(ex.Message + " " + ex.StackTrace);
}

How can I get WinForms to stop silently ignoring unhandled exceptions?

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.

Problems with "global" exception handlers for unhandled exceptions in multithreaded WPF

I have a program that, among other things, needs to be able to refresh the contents of a directory when the user tells it to. The actual task doesn't really matter, but this is the simplest way of causing this problem to occur that I know of.
If I tell it to open a directory that doesn't exist, I get the "unhandled exception" dialog in VS with a stack trace of, from outer to inner:
[External code]
Textbox PreviewKeyUp event
[External code]
ClassA's path property being set
ClassA's internal path update function being called
A call to the INotifyPropertyChanged event
[External code]
A call to the getter for ClassB's list of children
A call to ClassB's internal directory list function
And then it fails inside this internal function. I have the following in my App.xaml.cs:
private void Application_Startup(object sender, StartupEventArgs e)
{
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
Application.Current.Dispatcher.UnhandledException += new System.Windows.Threading.DispatcherUnhandledExceptionEventHandler(Dispatcher_UnhandledException);
}
But neither of their exception handlers are being called. If I run this program from outside VS, I don't get notified of an exception at all, it just breaks because of the invalid input. And yes, the Application_Startup event is being called. How can I properly "trap" this exception so I can provide a friendly error message and kill the program?
Oh, and if I put a try/catch anywhere up the call stack past an External Code call, it doesn't catch it, either.
[edit]
After some searching, I'm pretty sure this is a side effect of WPF's binding system. Because the DirectoryInfo is being created successfully (even on a directory that doesn't exist), the error doesn't occur until a binding goes to retrieve the value - and WPF eats binding exceptions.
I'm leaving this open in case anyone has any further ideas, but I think I the best I can do is abandon lazy-loading if I think it can lead to exceptions, at least until the application is more proven.

Try attaching to the apps DispatcherUnhandledException.
private void Application_Startup(object sender, StartupEventArgs e)
{
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
Application.Current.Dispatcher.UnhandledException += new System.Windows.Threading.DispatcherUnhandledExceptionEventHandler(Dispatcher_UnhandledException);
this.DispatcherUnhandledException += ...
}