Catching unhandled exceptions in the finalizer under .NET 2.0

[=?iso-8859-15?Q?Stefan_K=FChnel?=]

Hi!

We're having a problem with converting a program from .NET 1.1 to .NET
2.0. The program is kind of an AppServer (which can run as NT service or
as a console application), where we don't control which applications are
run inside it. Now we have a problem with one application which uses a
third party library and this library causes an unhandled exception in a
finalizer. This then brings down the whole server.

The cause of this is the different treatment of unhandled exceptions in
..NET 2.0 (http://msdn2.microsoft.com/en-us/library/ms228965.aspx). We
could work around this problem by setting the application compatibility
flag <legacyUnhandledExceptionPolicy enabled="1"/>. But I was wondering
if there is a better way to deal with this?

Thanks for any insight,
Stefan

 

[Dave Sexton]

Hi Stefan,

Try calling GC.SuppressFinalize on the incriminating object. If that's too
much of a pain because you are constantly constructing new instances then
create a class factory.

 

[David Levine]

Can you contact the author/vendor and have them fix the problem? That is the
easiest and best way to fix the problem.

There are some extreme measures you could use but they are non-trivial. You
could host the runtime yourself and set your own policy. You could
diassemble the offending library using ILDASM, fix the bug yourself in IL,
and then reassemble it using ILASM. There are other measures but I don't
recommend it for production code (e.g. use the profiling API to watch
for/deal with exceptions before the runtime escalates it to a UE, or even
dynamically rewrite the code on the fly).

These are probably not worth the effort - the legacy workaround is easier
and less error prone.

 

[=?iso-8859-15?Q?Stefan_K=FChnel?=]

Hi Dave,

Try calling GC.SuppressFinalize on the incriminating object. If that's too
much of a pain because you are constantly constructing new instances then
create a class factory.

since we're not controlling the creation of those objects in any way,
this is nothing we can do.

Since we need to have a solution that works independent of any
particular application and we don't know in advance if the objects of
any particular class have a buggy finalizer, I think all solutions based
on modifying the creation won't work.

Thanks anyway,
Stefan

 

[=?iso-8859-15?Q?Stefan_K=FChnel?=]

Hi David,

Can you contact the author/vendor and have them fix the problem? That is the
easiest and best way to fix the problem.

Certainly, but since we already have a version out and we need to be
backward compatible, this is sadly not an option.

There are some extreme measures you could use but they are non-trivial. You
could host the runtime yourself and set your own policy.

Yes, this seems from all I can tell the only viable if nontrivial
alternative. Do you have a good reference for this?

You could
diassemble the offending library using ILDASM, fix the bug yourself in IL,
and then reassemble it using ILASM.

This would work only for the one known offender, but is not a general
solution, so sadly not an option either.

There are other measures but I don't
recommend it for production code (e.g. use the profiling API to watch
for/deal with exceptions before the runtime escalates it to a UE, or even
dynamically rewrite the code on the fly).

Haven't thought of these but then I'd rather do the hosting. ;-)

These are probably not worth the effort - the legacy workaround is easier
and less error prone.

Yes, that's probably the way we go for the moment, even though it is not
really satisfactory.

Thanks a lot,
Stefan

 

[David Levine]

Hi David,



Certainly, but since we already have a version out and we need to be
backward compatible, this is sadly not an option.


Yes, this seems from all I can tell the only viable if nontrivial
alternative. Do you have a good reference for this?

There's a book written by Steven Pratschner.called Customizing the .NET
Runtime,
http://www.amazon.com/Customizing-Microsoft-Framework-Pro-Developer-Paperback/dp/0735619883
Great book, gets into all the low-level APIs used to take control over the
runtime.

He also authored this article:
http://msdn.microsoft.com/msdnmag/issues/01/03/clr/

I found this link but I have not evaluated it....
http://www.codeproject.com/dotnet/simpleclrhost.asp

 

[=?iso-8859-15?Q?Stefan_K=FChnel?=]

Hi David,

There's a book written by Steven Pratschner.called Customizing the .NET
Runtime,
http://www.amazon.com/Customizing-Microsoft-Framework-Pro-Developer-Paperback/dp/0735619883
Great book, gets into all the low-level APIs used to take control over the
runtime.

He also authored this article:
http://msdn.microsoft.com/msdnmag/issues/01/03/clr/

I found this link but I have not evaluated it....
http://www.codeproject.com/dotnet/simpleclrhost.asp

Thanks a lot for those references. Will look into those for a future
release.

Stefan