Check if windows service has been forcefully shut down or crashed

Question

I have a windows service written in C# .NET framework 3.5 and would like to know the best way to check if previous shutdown of a service was regular.

Upon starting the service, there should be a check if the last shutdown was regular (via stop service button in services management) or if somebody just killed the process (or it crashed for some reason not directly linked to the service itself).

I thought about writing encrypted XML on a hard drive upon starting a service, and then editing it with some values when service is being stopped. In that way, after I start the service again next time, I could check the XML and see if the values were edited in correct way during shutdown, and if they were not I'd know the process was killed or it crashed.

This way seems too unreliable and not a good practice. What do you suggest?

Clarification: What the service does is it sits on a server and listens to connections from client machines. Once the connection has been established, it communicates to a remote database via web services and determines whether they have right to connect (and therefore use application that is the caller). One of the aspects of protection is concurrency check, and if I have a limit set to 5 work stations, I keep the TcpClient connection alive from windows service to, let's say 5 workstations, and the sixth one cannot connect.

If I kill the service process and restart it, the connections are gone and I have 5 "licensed" apps running on workstations, and now there are 5 free connection slots to be taken by 5 more.

Answer 1

Unless the service is running some sort securiy system that you need to have a "tamper" proof system i dont see why using a file is a bad solution.

Personaly i think a encrpted xml file is overkill, a simple text file should be enough.

Answer 2

I think you are on the right track, I'm not sure why you want to edit the values, just use the file (or a registry key) as a marker to indicate that the service was started and is running. During a graceful shutdown remove the marker. You then just need to look for the existence of the marker to know whether you were shutdown gracefully or crashed.

If you are finding that the file isn't created reliably, then make sure you are closing and flushing and disposing of the file object rather than relying on the garbage collector.

--- EDIT following clarification ---

So the requirement is for a licensing system and not simply to determine if the service was shutdown gracefully. I'm guessing that the desire is for the 'licenses' to be cleared on a graceful shutdown and restored following a crash, the scenarios are interchangeable.

I would probably use a database backing store, with suitable security, to hold the license keys at the server. As each client connects and requests a license they are provided with a key that has to be presented for each communication from the client. The server is obviously verifying that the presented key is valid for the current session. Should the server be gracefully shutdown it can clear the key table, if it crashes then the keys would still be present and can be honoured. That's probably the simplest approach I can think of that's secure.

If there's yet more to the story then let us know.

Answer 3

I would suggest to use the EventLog. Add a log event when a service start or stops and read through the event logs to detect anomalies.

Here's a basic sample from CodeProject. Here's a walkthrough from MSDN how to create/delete/read event logs and entries.

Answer 4

I also cant see anything bad using a file. You could even use this file to log some more information.

Eg. you could attach to the AppDomains Unhanded Exception event and try to log that exception. Or you could evaluate how log your service has been running/not running (parsing a logfile for that task is a little bit harder).

Of course - this is not an excuse for not using logfiles.

Answer 5

I went with this in the end: Service used to check up on the connected workstations to see if they're alive, but now I've built in periodical check from all the workstations as well (they connect through a common router dll where I've built in the check). Every 10 seconds the connection is verified, and if there is none, the client will try to reconnect in 15 seconds, which will be successful if there was just a temporary network problem, but will fail if the service was shut down forcefully (since all it's Tcp objects will be lost).