How do you log error when the process is halted or computer went down?

Question

How do you log a event if the program process is halted or when the processing computer is down?

I'm using Microsoft Enterprise library to do all my logging but I'm not sure how to log the above situation.

Answer 1

You can't. There is nothing to do the logging. The best you can do is an external monitor program, but that can't really tell much about what happened unless you litter your code with "twitter"-style logging; "I'm not attempting to contact the database", "I contacted the database", "I'm sending a query", ...

Answer 2

Heartbeats. A second machine listens constantly for a heartbeat, then screams if it fails to arrive. Of course slow processing/network issues occasionally generate possibly incorrect warnings, but the underlying causes are often important signs of pending problems.

Answer 3

There are a few options here. If you are not concerned with what I call ETW (end of the world) exceptions like StackOverflowException (how about that?) you could wrap everything in a try-catch-finally block in your entry point:

static void Main()
{
   try
   {
       // Run...
   }
   catch (Exception ex)
   {
       // Log failure.
   }
   finally
   {
       // Log shutdown.
   }
}

If you are using threading at all, things become a lot messier. Using delegates and the Begin/End Invoke pattern properly will propagate exceptions onto the current thread (when the EndInvoke method is called). Using the Thread class will make things more complicated. I can safely assume there is a way to cope with this (but I personally don't use clean threads all that often). I have read on the tubes that for some reason a ETW exception in your AppDomain is fatal for the entire AppDomain (even though it shouldn't be if it doesn't happen on your main thread); don't rely on threads if you want to side-step these.

As far as ETW exceptions go your absolute best bet is to isolate the potentially buggy code in another AppDomain (out of- or in- process) and access it via Remoting. Remoting will shield you from these exceptions. Remoting will also shield you from unexpected terminations of the target app. Nothing will save you from the workstation turning off unless you can clean up within a limited timespan (Windows will attempt to close your app in a deterministic fashion first).

I have experimented with CER, but have come up with nothing. You might want to look at this MSDN article.