Unhandled Exception: Cannot print exception string because Exception.ToString() failed.

I ran an internal tool, and it communicated with a back-end service, and then displayed the error

Unhandled Exception: Cannot print exception string because Exception.ToString() failed.

I can't figure out what that even means.

I waited a little while, then tried again,

It worked the second time.

Didn't even need to turn it off and back on again.

Comments (14)
  1. 12BitSlab says:

    Raymond, I used to see that with .Net 1.1 managed code. Haven’t seen that from 2.0 and up.

  2. Ben Voigt says:

    I can readily believe that collecting exception details into a string might run out of memory.

    That said, they managed to log/display *something*. I feel that before throwing up one’s hands in defeat, it would have been better to fall back to just the exception typename, which gives at least some information about what bombed.

  3. Clearly the developer never tested the exception path. I’d wager that the custom Exception subclass is NRE’ing on some field of its.

    1. Joshua says:

      A search of the internet shows a bunch of random hits with the exact same message text. I’m led to believe the error message really is in some older version of Exception.ToString() itself, that is, it’s wrapped in a try-catch and returns that constant string on failure. I checked sourceof.net and it’s not there now though.

      1. NTAuthority says:

        It’s still there in the open-source CoreCLR: https://github.com/dotnet/coreclr/blob/ff328b606c4edad13e9a211a8d89288340952f4c/src/vm/excep.cpp#L5947 (the reference string is elsewhere, an internet search for the constant shows it’s said string) :)

      2. ranta says:

        CoreCLR calls that error message IDS_EE_EXCEPTION_TOSTRING_FAILED: https://github.com/dotnet/coreclr/blob/bc146608854d1db9cdbcc0b08029a87754e12b49/src/dlls/mscorrc/mscorrc.rc#L1409
        I don’t see any code loading that string though. Perhaps it’s only used in the full .NET Framework.

  4. DysgraphicProgrammer says:

    Classic Fail-Fail. The tool fails, then while trying to print an error message, it fails at that. The programmer probably never tested fail cases.

  5. MV says:

    I’ve hit something like that, only there was no try/catch around the call to exception.ToString(). Deep down something went wrong, it created a subclassed Exception object, added a set of key/value pairs to (with diagnostic info), then threw it. Near the top it caught the exception and tried to log it by dumping out the key/value pairs. Only it used value.ToString(), and if the value was null, the act of ToString()-ing it would throw an exception. So instead of a nice clear error message, you get an “impossible” situation where a throw deep down made it all the way out without being caught (or so it seemed) and the program crashed. Took FOREVER to figure out what was going on!

  6. Mike S says:

    My best guess is that whatever threw the exception passed in a null message. ToString() tried to read the message, failed, and fell over.

  7. It’s a .NET Framework error.

    And if I had to guess, I’d say someone didn’t do a good job of creating an exception object in ASP.NET. But that’s based on a mere unreliable assumption.

    1. cheong00 says:

      Yup. .NET v4.5 introduced a feature that it’ll delay initialization of all classes until their first usage. Unfortunately it caused bug on static/const strings that assumed the String class is always initialized.

      In the second time you run it, the String class (and possibly the class that caused the bug) is initialized hence the code works the second time.

      The bug is fixed in other v4.5.x updates and v4.6.

      1. Kathy O'Hara says:

        If true, turning it off and on again would have actually prevented it from working.

  8. nobugz says:

    IErrorInfo.GetDescription failed with E_FAIL(0x80004005)

    Well, that was accurate. Special kudos to E_UNEXPECTED = “Catastrophic failure”, back with a vengeance in WinRT/UWP. Very accurate, the failure to report a decent error was truly catastrophic.

  9. Neil says:

    Just as well .ToString() worked on the unhandled exception exception, otherwise we could have been in for a long night…

Comments are closed.

Skip to main content