What reasons are that a `finally` block of code might be skipped?

Question

I am refactoring my Windows Service so that access to the named Mutex is centralized in the worker thread's method. Instead of releasing it in OnStop() and ~DerivedService() it now should be released in the finally block.

I've observed skipping of destructor calls when I hit Shift+F5 to stop debugging and expect that and a crash (more serious than politely raising an exception) would be the only reasons to skip the finally block.

As I am coding a Service and its worker thread I was hoping to clear up any nasty surprises here before the rigmorale of replacing service code, logging in and out, attaching debugger etc.

Thanks.

Answer 1

There is a built in mechanism in the Windows Mutexes to handle the situation where a program or thread ended unexpectedly, without releasing the mutex. If the thread currently holding the mutex quits, the mutex will become unlocked automatically, but in a special abandoned state.

Instead of focusing too much on cleaning up, make a special routine whenever the mutex is acquired and its state is abandoned. In that case you should probably do some extra consistency checks on the protected resource - it could have been left in any state.

Answer 2

There are many (in reality a few) reasons why a final block won't execute. In general if you call Environment.FailFast, some asynchronous exceptions (StackOverflowException, ExecutingEngineException), shutting down violently your PC :-), and (often forgotten) if there is an exception in a finalizer method

Read for example here Does the C# "finally" block ALWAYS execute? and In C# will the Finally block be executed in a try, catch, finally if an unhandled exception is thrown?