0

We've added an UnhandledException handler to our application, but it seems like it doesn't always trigger. It works fine for me, on some Virtual Machines, but for one of my colleagues it never runs the attached delegate. We create an object kept alive by our app which sole purpose is to listen for unhandled exceptions:

public UnhandledExceptionTracker()
{
    AppDomain.CurrentDomain.UnhandledException += TrackUnhandledException;
}

I was able to reproduce the issue on my machine by running the application as Admin, but my colleague wasn't doing this (as far as we could tell). The windows user running the application also didn't seem to have any elevated permissions compared to my account.

I've checked similar issues, and none of suggestions seemed to make a difference - SecurityPermissions attribute, ThreadException handling through a WinForms Application object (not teh case of our app).

Our application is native C++, built with the Visual Studio 2013 compiler (v120), and uses .Net 4.5.1 for the managed components. Connection between both sides is done to C++/CLI. On the application startup, our native code spins up the UnhadledExceptionTracker object and keeps hold of it.

I tested the behaviour with message boxes popping up when the UnhadledExceptionTracker gets created and destroyed (never destroyed if the application crashes as expected), and when the unhandled event handler runs (runs for me, not when running as Admin, not my colleague).

Has anyone experienced similar issues and might know how to make this work for any user?

EDIT: After further investigation, it seems this might only be an issue for some exception types, and not only for different users/permission settings.

In the original testing, deleting a managed library that got loaded at run-time (not at application start-up), a managed System.IO.FileNotFoundException would be thrown but the UnhandledException handler wouldn't run.

Throwing a native std::exception during execution causes the UnhandledException to run.

Zepee
  • 1,640
  • 3
  • 20
  • 40
  • http://stackoverflow.com/a/13567016/17034 – Hans Passant Jun 20 '16 at 11:09
  • Thanks @HansPassant. Your previous post seems to list exceptions which won't be caught by an application. In our case the *same* exceptions are not caught when ran by different users/machines. I didn't spot any explanation to our behaviour, did I miss something? – Zepee Jun 20 '16 at 12:38
  • I've done some more investigation and added some detail. It seems like the exception type might indeed be related to whether the UnhadledException handler gets triggered, but the original exception did not seem related (as far as I can tell) to the ones mentioned in your previous post. I didn't realize more information was required, often pointing that out is enough.. clearly my original post was terribly offensive to your editorial sensibilities. – Zepee Jun 20 '16 at 14:16
  • Ah, now it is obvious. I added a bullet to the list. – Hans Passant Jun 20 '16 at 14:28
  • Ok, so it seems this exception type would fall in this category of exceptions that can't be caught (although it isn't thrown on start-up). How come though, the handler does run for me when running the application in non-Admin mode? (release build, no debugger attached, etc.). Is it a case that it might be caught, but not in certain environment configurations? It seems for some of these exception types, being unable to catch the exception is a security feature to prevent you doing bad things, so it'd make sense to me that they wouldn't be caught in any circumstances. – Zepee Jun 20 '16 at 15:05

0 Answers0