Wednesday, March 28, 2007

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, 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.


quantboy said...

Thanks for linking to my page. A question- if a thread from the threadpool throws, can you prevent that exception from taking down the entire application by wrapping the code that thread runs within a try-catch block?

Ian Dykes said...


I've posted an answer here. But the simple answer is yes.


Joshua Williams said...

Did you find a solution to this problem? I'm experiencing the same thing.

Joshua Williams said...

Please ignore my premature post.. I should have read the full article first.

Ali Umut said...

Hi...I am suffering same .net framework 2.0 service crash problem.
How can you implement unhandledexceptionhandler for the windows service.
I implemented it at Service OnStart
for current application domain
but I can not fire the handler method despite throwing the unhandled exception.Would you mind helping me about this?

Peter Larsen said...

I've run into a similar-looking error message and was eager to find the information at the link in your blogpost labeled "Tech Notes :: DotNet Runtime Error." However, the page this links to is no longer available. Do you know of any other resources that would help me to decode this message?

Ian Dykes said...

I have since read an MSDN Magazine article that covers pretty much everything that I originally posted here. Maybe that article will help?

Ian Dykes said...

Thanks to Peter for letting me know the link was dead. I've updated the post now with more information

Cory Mathews said...

I ran into this as well and wrote up an article on how to find and solve errors similar to it using the p7 listed above and IL Disassembler.