|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Catching unhandled exceptions in the finalizer under .NET 2.0Hi!
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. -- Show quoteDave Sexton "Stefan Kühnel" <stefan.kueh***@gmx.net> wrote in message news:MPG.1fa807bc3b2c3ae3989680@msnews.microsoft.com... > 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 Dave,
In article <ehrBDH49GHA.3***@TK2MSFTNGP03.phx.gbl>, dave@jwa [remove.this]online.com says... > Try calling GC.SuppressFinalize on the incriminating object. If that's too since we're not controlling the creation of those objects in any way, > much of a pain because you are constantly constructing new instances then > create a class factory. 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 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. Show quote "Stefan Kühnel" <stefan.kueh***@gmx.net> wrote in message news:MPG.1fa807bc3b2c3ae3989680@msnews.microsoft.com... > 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 David,
In article <Os8LAQ69GHA.4***@TK2MSFTNGP03.phx.gbl>, SnipHereDlevinenntp2AndH***@wi.rr.com says... > Can you contact the author/vendor and have them fix the problem? That is the Certainly, but since we already have a version out and we need to be > easiest and best way to fix the problem. backward compatible, this is sadly not an option. > There are some extreme measures you could use but they are non-trivial. You Yes, this seems from all I can tell the only viable if nontrivial > could host the runtime yourself and set your own policy. alternative. Do you have a good reference for this? > You could This would work only for the one known offender, but is not a general > diassemble the offending library using ILDASM, fix the bug yourself in IL, > and then reassemble it using ILASM. solution, so sadly not an option either. > There are other measures but I don't Haven't thought of these but then I'd rather do the hosting. ;-)> 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 Yes, that's probably the way we go for the moment, even though it is not > and less error prone. really satisfactory. Thanks a lot, Stefan
Show quote
"Stefan Kühnel" <stefan.kueh***@gmx.net> wrote in message There's a book written by Steven Pratschner.called Customizing the .NET news:MPG.1fa94e4ce285a073989682@msnews.microsoft.com... > Hi David, > > In article <Os8LAQ69GHA.4***@TK2MSFTNGP03.phx.gbl>, > SnipHereDlevinenntp2AndH***@wi.rr.com says... >> 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? > 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,
In article <unfSevJ#GHA.4***@TK2MSFTNGP03.phx.gbl>, SnipHereDlevinenntp2AndH***@wi.rr.com says... Show quote > >> There are some extreme measures you could use but they are non-trivial. Thanks a lot for those references. Will look into those for a future > >> 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? > > > 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 release. Stefan  |
|||||||||||||||||||||||
Other interesting topics