Prevent Unhandled Break Exceptions

Question

We have a working Azure role that works with a heavy load of an asynchronous process, with many terminations in I / O streams, etc.

Sometimes unhandled exceptions occur in asynchronous callbacks that we don’t have. This, in turn, causes the role to fail.

In non-Azure ASP.NET applications, this can be avoided by including an outdated unhandled exception policy in aspnet.config:

<configuration> <runtime> <legacyUnhandledExceptionPolicy enabled="1" /> <runtime> <configuration> 

Is there a way to do the same for the Azure worker role? We tried to put this in app.config for the role project, but it did not work (since we probably should somehow get it in the WaWorkerHost.exe.config file).

We know AppDomain.CurrentDomain.UnhandledException and Application.SetUnhandledExceptionMode and How to catch an unhandled exception in the Windows Azure (Worker) role , and this does not solve our problem.

Answer 1

Just read your thread because I am experiencing the same with webrole. Now I have added your code snippet and checked to see if I repeat this error. Some research has been done on the AppDomain class: http://msdn.microsoft.com/en-us/library/system.appdomain.aspx . Actually, I was looking for an unhandled exception policy, but could not find it. But I found the event "UnhandledException" http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception.aspx .

But you wrote that this does not work. Because it will affect me later - I will run a third-party component with open source as the azure desktop - I did some research.

I will try to create a new AppDomain for the third pary-code - and if an exception occurs, it will lead to the failure / unloading of the newly created AppDomain, and not the current code run. Another solution is likely to be to create a new process that, I believe, works more.

EDIT: I was revising this topic: in version 2.0, an application domain stall was introduced if a thread (not the main thread) experiences an error in the class library. It seems that even a separate ApplicationDomain will not help. As I understand it, this design should help debug errors hidden in libraries with catch exceptions at the library level and handle them accordingly. But what annoys me - what happens if we use libraries of third-party classes that we do not control? Then it seems that we are stuck if our problem is small for the supplier to solve it at the right time.