Catastrophic regression introduced in .NET 6.0.1 WinForms, completely broke Paint.NET v4.3.6

• .NET Core Version: 6.0.1

Problem description: Yesterday I rolled out a new update for Paint.NET, version 4.3.5. After quickly pushing out a hotfix (v4.3.6) for something that I broke in the code, I then received numerous reports of another catastrophic breaking issue that rendered the app completely broken.

After many hours it was finally determined that the culprit was having a certain app setting disabled (the default is enabled): “Translucent windows”.

I’m pretty sure this was caused by a bug (or bug “fix” ?) introduced in .NET 6.0.1, as it doesn’t happen in the previous version of my app (v4.3.4) on .NET 6.0, I had very few changes in the new version, and the workaround I found suggests a change in behavior surrounding Handle, IsHandleCreated, OnHandleCreated(), OnHandleDestroyed(). I’ve since published a new update with that workaround fix applied and everything works fine.

There’s a big discussion on my forum that details the issue, the pleas for help and rollbacks, the troubleshooting, the discovery of a workaround in the app, and subsequently a test build that saved the day: https://forums.getpaint.net/topic/119185-many-problems-with-436/

Here are some highlights:

• Dialogs always opening at the top-left of the screen, instead of centered or literally anywhere they’re supposed to be

• Truncated window size. This dialog should be 3-4x taller

• Progress dialogs that never complete and can’t be closed, resulting in a soft hang that requires Task Manager -> End Process

• Completely scrambled dialog layout for things like File->New, Image->Resize, etc.

Here is the change in 6.0.1 that is highly suspicious: https://github.com/dotnet/winforms/pull/6114 cc @RussKie

In my code, I’m setting the window’s opacity myself via SetWindowLongPtrW() and SetLayeredWindowAttributes(). This is because, way back with .NET 1.1 in 2004, there was some bug with Form.Opacity that I don’t remember the details of. (I may be able to remove this code now, but like … it ain’t broke so don’t fix it? maybe?) When “Translucent windows” is disabled, this ends up causing the window handle to be created in my Forms constructor (in a common base class that all other forms derive from), after SuspendLayout() and InitializeComponent(), and right before ResumeLayout(false). I do consider this to be a bug in my code, but it should only be a performance bug, and it’s been working fine for literally 18 years (Paint.NET 1.0 was originally released in May 2004 on .NET 1.1).

My fix, which is in the frantically released 4.3.7 update, is to first check this.IsHandleCreated before grabbing this.Handle to manually set the form’s opacity (via SetWindowLongPtrW() and SetLayeredWindowAttributes()).

The behavior of the bug(s) seems to indicate some kind of disconnect between what WinForms thinks the handle is, and what handle Win32 is using, or maybe a disconnect between various parts of WinForms itself. Dialogs aren’t closing properly, layout is all broken, every new dialog is at the top-left corner of the screen instead of centered, etc. The app will soft hang because modal progress dialogs don’t close when they’re supposed to. It’s just a total disaster.

Expected behavior: Everything works great. In reality, not even close 😦

Minimal repro: Here’s a ZIP of the “cursed” Paint.NET v4.3.6 build, in portable (self-contained deployment) form: https://www.dotpdn.com/files/zip/test/paint.net.4.3.6.portable.x64.zip

Launch the app by double-clicking paintdotnet.exe. You should be able to launch things like File->New, Image->Resize, Layers->Rotate/Zoom, and run effects and adjustments and everything works fine.

Next, go into Settings (gear icon at top right of main window), then uncheck the box “Translucent windows”. This is supposed to only affect the floating tool forms, since they’re the only forms that use Opacity. Anyway, close the window and then try all the things listed above (File->New, etc.). Everything will be completely, catastrophically broken.

I’m able to provide access to my solution/code for MSFT employees thanks to an NDA/license that @richlander and I set up a few years back. I can then easily show you which lines of code to change to make things broken/fixed.

[rickbrew]

Also, to vent a bit, how on earth was a change like this approved for a servicing release of .NET ?! I am completely baffled by this. Please don’t do this again 😦 It took hours of frantic troubleshooting and debugging to figure this all out, and a lot of my users/customers were really unhappy. I’d like to trust that I can deploy any new .NET 6.0.x update without having to go through a full beta release cycle of my app. Since there’s a servicing release every month, that would enormously increase my deployment times and costs for even simple bugfix releases.

[rickbrew]

Many thanks for fixing this so fast @dreddy-work ! I’ll be fixing Paint.NET to not do this sort of thing in the first place, of course. I found some other early forced Handle creation locations that need patching, although thankfully none of them have caused anything other than a performance optimization opportunity.