UnhandledException in Windows Service

[Groundskeeper]

I can't seem to get a custom UnhandledException handler working for a
Windows Service I'm writing in VB.NET. I've read the MSDN and tried
various different placements of the AddHandler call, to no avail.

Here's the code I'm using, all of which is in the main service class:


Protected Overrides Sub OnStart(ByVal args() As String)

AddHandler AppDomain.CurrentDomain.UnhandledException, _
AddressOf UnhandledExceptionHandler
Throw New Exception

End Sub

Sub UnhandledExceptionHandler(ByVal sender As Object, _
ByVal e As System.UnhandledExceptionEventArgs)

Me.EventLog.WriteEntry("This entry will never be written, " & _
"because the programmer doesn't know what he's doing.")

End Sub



Any help would be appreciated, so if you want to be appreciated by an
idiot, please help.

 

[Jay B. Harlow [MVP - Outlook]]

Groundskeeper,
AppDomain.UnhandledException only handles unhandled exceptions.

The OnStart routine has Try/Catch around it, hence the
UnhandledExceptionHandler is not called.

You can tell that OnStart has a Try/Catch around it, because if OnStart
throws an exception the service remains at in the Stop state, with an error
that is automatically logged.

Note its common to directly or indirectly to use Asynchronous Delegates in a
Windows Service, AppDomain.UnhandledException is not used for Asynchronous
Delegates either, you need to be certain to use end EndInvoke with
Asynchronous & catch the exception there, with possible logging. As far as I
can tell the System.Timers.Timer.Elapsed event is called via an Asynchronous
Delegate, which means you should wrap the Elapsed event handler in a
Try/Catch so as not to loose the Exception.

As far as I can tell ThreadPool.QueueUserWorkItem uses
AppDomain.UnhandledException so you should be safe there. This goes for
System.Threading.Timer also.

Hope this helps
Jay

 

[Groundskeeper]

That helps, thanks.

The service in question runs a timer (System.Timers.Timer) to watch for
files to process. (Earlier versions had used the filesystemwatcher, but
ran in to problems with it, but that's another story.) From what you
say, it sounds like simply wrapping the code in the timer's Elapsed
event and the OnStart and OnStop service events in Try/Catch blocks
should catch just about anything I can hope to catch.

Out of curiosity, is it only through trial and error that one can
discover which procedures can be expected to raise errors to a global
handler for unhandled exceptions? Put another way, when is adding a
handler for unhandled exceptions useful/needed in a Windows Service?

 

[Jay B. Harlow [MVP - Outlook]]

Groundskeeper,

say, it sounds like simply wrapping the code in the timer's Elapsed
event and the OnStart and OnStop service events in Try/Catch blocks

I am saying wrap the Timer's Elapsed event in a Try/Catch block.

The OnStart & OnStop are already wrapped in Try/Catch blocks! (inside of the
ServiceBase class)

Out of curiosity, is it only through trial and error that one can
discover which procedures can be expected to raise errors to a global

Basically that is it & reading the documentation
(http://msdn.microsoft.com/library).

Put another way, when is adding a
handler for unhandled exceptions useful/needed in a Windows Service?

When you are using ThreadPool.QueueUserWorkItem & System.Threading.Timer.

My observations are based on .NET 1.1 (VS.NET 2003) things may very well
change in .NET 2.0 (VS.NET 2005 aka Whidbey, due out later in 2005) & .NET
1.0.

Hope this helps
Jay

 

[Groundskeeper]

I really appreciate your replies. Sorry I didn't reply more recently;
I'm new to Google groups and had expected an email notifying me of any
activity on this thread.

What I meant by suggesting that OnStart and OnStop should have
Try/Catch blocks inside them is that this way, I can catch the errors
in my code and handle them myself, rather than relying on the default
handling in ServiceBase.

Once again, this idiot appreciates your help.

 

[Jay B. Harlow [MVP - Outlook]]

Groundskeeper,

What I meant by suggesting that OnStart and OnStop should have
Try/Catch blocks inside them is that this way, I can catch the errors
in my code and handle them myself, rather than relying on the default
handling in ServiceBase.

How are you going to "handle them yourself"? Log the exception? If you are
"simply" going to log the exception then there is NO reason to put a
Try/Catch in OnStart!

The default handling already logs it. By Overriding the ServiceBase.EventLog
property you can change where the exception is going to be logged!


I generally only use Try/Catch when there is something specific I need to
do; logging is not something specific enough to do... (unless of course the
routine requires a Try/Catch for logging, such as the ones I discusses...


Hope this helps
Jay