Paint.NET finally gets error handling for plugins

For the longest time, any unhandled exception in Paint.NET caused a generic “Oops sorry, go check the crash log on your desktop” error dialog. It’s not really that helpful, and it always points the blame in my direction even when it’s a plugin’s fault.

So, for v3.20 there is a real error dialog for this! If you’re running an effect or adjustment plugin and it doesn’t handle an exception, you’ll get the following dialog instead.

(quick digression: yes, command link buttons in v3.20 now look more like “real” command link buttons in Vista)

Clicking on the Error Details button will show the user details such as the file name of the plugin, its name, and the exception text. If the author implements a [PluginSupportInfo] attribute tag on the effect type and/or assembly, then additional information will be displayed such as author, copyright, and website URL.

If a plugin fails to load, you’ll get this:

Clicking on it reveals the reason why, although this text is really meant to serve as diagnostic information for the plugin author. I don’t expect non-developers to care about most of this except for maybe the file name.

In this case, Ed’s Surface Blur effect was deriving from a class in PaintDotNet.Effects.dll that was really only supposed to be used internally, and that is now using a different base class in v3.20. So his code is all confused and he will need to release an update. The other 10+ effects in his DLL’s still work fine though 🙂

Anyway, hopefully this will relieve my inbox a little and I won’t receive crash reports for plugins anymore.


8 thoughts on “Paint.NET finally gets error handling for plugins

  1. Rhyelys says:

    Great, but is possible, if I choose close, saves current works?

    Like image_autosave01.pdn, image_autosave02.pdn? A message like “Paint.Net will try save your work”

    Humm, or maybe auto safe option will work great with it. 🙂

  2. Christopher Morgan says:

    Hi Rick,

    I’m a big fan of Paint.NET (and .NET for that matter) and am currently prototyping some code for my team using System.AddIn to demonstrate application resiliance in the case where AddIns throw exceptions. I’m impressed by the dialog seen at the top of your page and would like to replicate the same behaviour.

    I’m currently looking at the scenario where a badly-behaved AddIn, which has been loaded into its own app domain, throws an exception from a child thread. I would then like the application to offer to Unload the AddIn, Restart the App or perhaps Restart the AddIn.

    I’ve tried making use of AppDomain.UnhandledException and Application.ThreadException events which have enabled me to capture information about the AddInToken, based on the article from the CLR team ( ). Unfortunately, I’m not having much luck shutting down the problematic AppDomain as I’m still seeing the original unhandled exception appearing at the top-level.

    Could you possibly offer some source code, snippets or advice on how to do The Right Thing?


  3. Björn Waide says:

    Hi Rick, hi Christopher,

    I’m having exactly the same problem but we have to stick to .Net 2.0 so we cannot use the newly added AddIn framework. As far as I’ve seen comments on this topic what you’ve done isn’t possible with .Net 2.0 and in-process plugins?!? Obviously, it is, but could you please share at least a hint how to implement a solution like you did?

    TIA and best regards,


  4. Björn Waide says:

    Hi Rick, I know that you are still using .Net 2.0, that’s why I was so surprised. But I guess you haven’t fully understood Christophers and my concerns. I had a look in your code and your are not dealing with the situation we had in mind. Your solution will probably work fine for PDN, but it’s not a 100% solution because it will not catch exceptions that are thrown in Threads started by an effect. Seems to be an unlikley scenario in your case, but not in mine. For further information see

    Sorry for bothering you!

Comments are closed.