EventType clr20r3 From Windows Service

In the final throws of testing part of our system on the new .Net 2.0 code, we deployed a few of our Windows services to a production server in preparation for going live with it. Luckily for us that we did because we found that one of the services appeared to stop occasionally.

The service is responsible for notifying our customer's applications of events on their accounts as part of our Push SMS API service, which for many customers is a very important part of the services we offer. So we needed to get this problem fixed before going live, but we had a number of problems with finding out why the service was stopping.

We use log4net for logging within all of our applications, but these log files did not show any errors being thrown from the service.

However, the Event Viewer did trap an error. It was in the category of a .Net Runtime 2.0 Error, being logged in the Application section of the Event Viewer. The error message looked like this:

EventType clr20r3, P1 t1f44vcumbpfz21uvtobhdijm4egyfae, P2 1.0.2643.18660, P3 460a41c8, P4 mscorlib, P5 2.0.0.0, P6 4333ab80, P7 4052, P8 27, P9 qvnotafqzyql5inknkn5msslsene3ln1, P10 NIL.

I think you'll agree its not that much help. Most of the errors were the same, but some had different garbled text in the P9 section.

The code that was running hadn't changed since the 1.1 build, and the service never used to stop on any errors previously. We have error handling that will log any error and allow the service to carry on in the event of any failures. Or so we thought anyway.

I was maybe 5 minutes away from raising a support call with Microsoft, when I found this article that explained how I could make the error message more useful: Tech Notes :: DotNet Runtime Error UPDATE: Original link seems to have died. See below.

The error is an example of an unhandled exception being thrown out of the application. You can make some sense of the error by implementing a handler for the UnhandledException event on the current AppDomain that your application is running in. This event will pass in the exception object that has been thrown, so you can log it to the Event Viewer in a more meaningful fashion.

From this we found the error and have now corrected it so the service doesn't keep stopping.

When the service started it would perform each task it was required to do in a method that we had queued in the ThreadPool. If this method managed to throw out an exception, then of course that current Thread would exit. Now, we shouldn't have been throwing exceptions out of this method anyway, but the 1.1 Framework didn't seem to mind about it.

In the 2.0 Framework it seems that if a method that is in the ThreadPool throws, then that Exception takes down the application, in this case the Windows service. Personally I feel that this is a better way of doing it, as the 1.1 Framework was masking an error in our code. The error message could have been a bit more meaningful in the first place though.

UPDATE (3 Apr 2009): The original link that was the inspiration behind solving this no longer exists.  However if you are interested please check out Unhandled Exception Processing In The CLR from the MSDN Magazine for more information.