How to get notified if finalization is aborted?

During an application shutdown the finalization can be aborted if all finalizer did take longer than 40s to execute or if one finalizer does take longer than 2s to execute. In these cases no exception is thrown and I have a hard time to find out which one was the bad guy. Is there some tracing built into the CLR to find out which finalizer (call stack would be nice) did cause the **** of a finalizer during application shutdown

Yours,

Alois Kraus

.NET Development6

A trivial solution...

You can write an entry in a log, with the first instruction in each Finalize method...

The last entry in the log will indicate the class...

This is not so trivial since I do not know what finalizer which will most likely not contain the required log statements did cause the problem. In a big project you do not have every finalizer under your control to implement such things. I cannot assume that logging to disk will work anyway since e.g. FileStream might already be finalized -> no output. I still hope that there is some builtin logging inside the CLR which can be turned on to find such bugs.

Yours,

Alois Kraus

Hi Alois

There is currently no such logging in the .NET Framework. As you pointed out above, you cannot assume that filestream objects haven't been finalized so you can't log to disk.

Can I ask why you need to know which finalizer is being aborted If the process is shutting down, all your unmanaged resources should be freed automatically.

-Chris

Within a large project it is very difficult to check if the shutdown is really clean. Of course there is no guarantee that all finalizers are executed during shutdown but the finalization code should be as clean as possible. During shutdown you will find out very quickly if somebody did take locks which he should not have aquired in the finalizer because all application threads are suspended which does provoke a deadlock. It would be very interesting to find these weak spots to increase scalability (finalizer thread is hopefully not blocked) and reliability within our finalization code.

Yours,
Alois Kraus