PSP 2022 causes Explorer memory leak even after PSP quits

[hasl753]

Whenever I start PSP 2022, Windows Explorer experiences a steady memory leak. Private Bytes keeps increasing until Explorer uses several gigabytes of memory and then exhausts all available memory.

Even if I quit PSP or end it manually with the Task Manager, the Windows Explorer memory leak continues anyway until once again, Explorer exhausts all available memory.

Evidently even after PSP quits, something is left running around that keeps steadily consuming memory. Yet Task Manager doesn't show any other Corel-related processes.

This problem really got worse after Microsoft installed the update KB4023057 on October 1. That's when the real trouble began.

I'm running Windows 10 Home 20H2.

Anyone else experience anything like this? Any ideas?

[LeviFiction]

I have not experienced this. I do have KB4023057 installed, Windows 10 Pro 21H1 - build 19043.1237. Do you have to do anything inside PSP first? Or does it happen if you immediately close PSP without ever opening an image?

I would bring this up with Corel support. Though it may take a few tries to get them to forward you on to their engineering team.

The only Corel process I can think of that might interact with Explorer is the PSP Thumbnail add-on but as that's not connected to PSP directly I don't see why it would wait until PSP was open before starting to cause problems if that were the issue. You can of course always disable the add-on to be sure but I doubt it's the culprit.

[splash3313]

How sure are you that it is PSP 2022 that is causing the memory leak and not a faulty driver or memory, or a faulty component on your computer if not happening to others.
What process are you doing when you find the leak.
Have you tried task manager and highlighting windows explorer and press restart, that should just restart the desktop and release the memory.

Make sure you are using a legitimate version of PSP 2022 as pirated versions can cause memory leaks.

Closing a program will release all the memory being held from the general storage,
and as long as the process structures in the kernel that allowed it to manage the process running the program are not corrupted, they will be totally released as well.

So usually there is no problem ; kill the bad program, the OS bounces back.

Only if the bad program has somehow corrupted the kernel space memory will things really go south. This includes two external pieces of code as well. One is a leak in a shared library of code that the program needs and is loaded when the program starts. It may stay loaded after the program crashes or exits, and the next program that uses it will run the leaky code in it.