Event log for Windows Service app exceptions -- need better diagnostics

[SDS]

VS 2005 / .NET 2.0.50727 (Sept. CTP)

I've got a Windows Service application that I've pushed out to a few
other workstations. There is an unhandled except occurring somewhere
in the application at some point, but I can't debug it because the
diagnostic info written to the event log is nearly worthless. Here's
what I am getting:

EventType clr20r3, P1 myservice.exe, P2 0.7.0.19863, P3 435a627e, P4
myservice, P5 0.7.0.19859, P6 435a6276, P7 325, P8 42, P9
system.nullreferenceexception, P10 NIL.

How can I get more verbose diagnostics in the event log, including the
stack trace?

TIA

 

[Ollie Riches]

how about you add LOGGING to your application and LOG information that is
important...

 

[SDS]

How about staying on topic?

 

[Nicholas Paldino [.NET/C# MVP]]

He is. Services in .NET do not automatically log exceptions when they
are thrown. It's just not there.

You need to write it yourself. To that end, the ServiceBase class
assists you by providing an EventLog property where the log is set to the
application log, and the source is set to what is returned by the
ServiceName property.

You can write up a few try/catch blocks, and then write the exception to
the event log, and it should give you the information you want.

Hope this helps.

 

[SDS]

Thanks for the useful response, Nicholas. I wish all replies in
newsgroups could be as helpful as yours, but then again it's clear you
know what you are talking about.

Admittedly, I am being lazy at this point mostly due to the amount of
code, threading, and the fact that my service is in another AppDomain
from where the exception is occurring. It's just going to take me
forever to get all of the handling in place. That and I could've sworn
that .NET will write out stack trace debug info to the event log for
unhandled exceptions...

I wish there was a Service.Error global event handler simliar to
ASP.NET's... =(

 

[Nicholas Paldino [.NET/C# MVP]]

I'm kind of confused by the following statement:

and the fact that my service is in another AppDomain from where the
exception is occurring

Are you saying that you are creating another app domain in your service,
and the exception is happening there? If this is the case, then the app
domain is still in the boundary of your service (or at least the CLR that is
loaded in the process of your service). All you have to do is marshal the
instance of the service to your new app domain, and you can log the events
in the event log from the new app domain.

 

[SDS]

Yeah, you are totally correct there (except I don't think you can
marshal ServiceBase, but I do already have a class that is marshaled
for the purpose of connecting the domains), it's just one more thing to
deal with in the process of trying to track down one bug in a very
short period of time.

Always in a big damn hurry. Know what I mean?

 

[Nicholas Paldino [.NET/C# MVP]]

SDS,

Why not? ServiceBase derives from Component, which derives from
MarshalByRefObject, which means that you can marshal a reference into the
new app domain, and then have it call back into the app domain the service
started in.

However, this can have performance ramifications. You might be better
off having an event of some sort be fired, or making a call to your
ServiceBase-derived class on a method you define, which will indicate what
happens, and then you can do the work in the app domain of your service.

Oh, EventLog derives from Component as well, so you can marshal that by
reference across the app domain boundary as well.

 

[SDS]

I'm not sure, maybe you can, but at some point I made the decision to
not marshal the ServiceBase across AppDomains. Anyhow, like I said, I
have a class whose purpose is nothing other than to act as the
connector between domains, and it is this object that is marshaled.
I've added an EventLog member to this class and am now in the process
of setting up exception handling.