lewin76

You pretty much lost me with the surprising attitude about a simple zip file, which adds a single step to the process and is commonplace. I would have thought the time and effort put into tracking down and describing the issue would have been better received. I've often wished I could improve or extend paint.net but I can see now why that's not a thing. I'll add the requested file since I did the work to investigate and happen to have the repro, but the only way to attach it is via...Startup.1.zip zip; hopefully that makes sense and is expected. Finally, the first time Startup.1.profile was generated after renaming/deleting the file and running paint.net and passing a command line argument, the file was large (189kb). However, when I came back later, it had changed and was the same size as the one which previously caused the problem behavior (54kb), yet it still works. I repeated the process and confirmed it changes size likely based on some loaded state. Seemingly expected behavior, just thought it's interesting to note if you're comparing the before/after versions of Startup.1.profile and wondering why I originally said it was 190kb but it's small in the zip. Also, Startup.1.profile_bad in the zip file is the repro case which prevents command line behavior from working correctly, the others are currently working versions.

paint-diag.txt

I've tried a number of things like toggling or resetting config options in the Setting UI but nothing seems to work to restore the old behavior. I tried setting up a fresh install in Windows Sandbox, and the same version of Paint.net runs without issue and supports shell associations, in the sandbox. Imagining that it's likely some old bad persisted state, I started hunting for AppData files that I could purge. I found and renamed the `%localappdata%\paint.net` folder and just like that, the app works as expected. I made a backup of the problem state and tried to reduce it to a specific cause, and found if I simply rename `%localappdata%\paint.net\Optimization\Startup.1.profile`, the app works correctly, and it rebuilds the file when missing and goes from a 54kb bad version to a 190kb good version. So, it seems like on my machine there's some incompatible state stored in Startup.1.profile that causes file loading errors in the new version. A simple workaround for those impatient like me might be to rename the file, and let it regenerate for an immediate fix. If you're interested I can post the problematic file, just let me know.

My diagnostic info: paint-diag.zip

As a followup and to further depict and document the issue, here's the exact behavior that has regressed. File associations rely on launching the target executable and passing the file path as the first parameter. If I replicate that behavior, and execute paint.net and pass it file paths, it fails to open them. If I take those same files and try to open them with any other editor, they open fine. It's not content, it's not file types, it's not relative versus full paths, it's something about the shelled to instance of paint.net that decides to not open the given path and simply exit. If I don't pass it the path parameter, the app opens without issue. See attached for an example the hopefully confirms this in your eyes: (looks like size limits means I have to offload to imgur) https://imgur.com/a/zOTeCVN

Since the beginning of the month or so, I'm also seeing this behavior. File associations fail to have any effect, paint.net simply refuses to open when double clicking an associated file, or when right clicking -> open with -> paint.net. I see a spinner for a brief second and then nothing. I've tried uninstalling and reinstalling and my normal workflow of clipping from the screen with Greenshot and it opening paint.net via file association is completely broken.