System.Text.EncoderExceptionFallback

  • Article

Today I found the following e-mail in my inbox:

Hello According to this article, https://blogs.msdn.com/b/johan/archive/2008/01/31/using-windbg-hunting-exceptions.aspx written by you, you write that there are three "ever-present exceptions", I can see why they have to be on the heap, but why is 790ff624 3 36 System.Text.DecoderExceptionFallback 790ff5d8 3 36 System.Text.EncoderExceptionFallback Also always there? I always see them on the heep when I do a debug session. I have always discarded them. According to Tess, they are "not real exceptions", refering to that a print of all exceptions on the heap throws an error when the are printed. I think that the are put on the heap when the process is created, like the other three. But why? Why are they so important? I DEMAND an answer, because I love you and your blog :) I am just joking. I have written to you because I think that you know your ways around the CLR and the heap.

I thought the answer might interest others as well, so I decided to answer the e-mail here.

This is not an Exception

The reason why these are on the heap and are not possible to examine using !PrintException (!pe) is because they’re actually not Exceptions at all. They show up when you run !dumpheap -type Exception because they contain the word “Exception” in their name, but that’s it. The System.Text.DecoderExceptionFallback object for example derives from the DecoderFallback object. It’s a fail-safe mechanism that is used when you can’t class that is used then you can’t complete the decoding conversion.

So what is a Decoder Fallback?

There are different fallbacks you can use. You can use the DecoderReplacementFallback that will replace any byte sequence that it can’t decode with a predefined string. For example; the decoder comes across a segment it can’t convert. You’ve defined a DecoderReplacementFallback and it replaces the segment with “[unknown]”. Execution will then continue.

If you had instead defined a DecoderExceptionFallback a DecoderFallbackException (notice the difference?) would be thrown when the decoder came across the segment that it couldn’t convert and execution would stop after that.

Cheers! / Johan