Catching unhandled exceptions in the finalizer under .NET 2.0

  • Thread starter Thread starter =?iso-8859-15?Q?Stefan_K=FChnel?=
  • Start date Start date
?

=?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
 
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.
 
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.
 
Hi Dave,

dave@jwa said:
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.
Click to expand...

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
 
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.
Click to expand...

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.
Click to expand...

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.
Click to expand...

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).
Click to expand...

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.
Click to expand...

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

Thanks a lot,
Stefan
 
Stefan Kühnel said:
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?
Click to expand...
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
 
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
Click to expand...

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

Stefan
 
Back
Top