Severe lag during memory cleanup, with a chance of causing Chrome or Vscode to crash

[Jef-Z]

Current Behavior

Excellent update. Thank you very much。

I noticed that after updating to version 3, memory cleanup works better than before. However, I encountered a confusion. I set memory cleanup to run every 2 hours. If I'm using VSCode or Chrome when cleanup starts, and I accidentally click on VSCode or Chrome during the cleanup process, VSCode or Chrome will force quit after cleanup completes. This has become a serious issue because I'm working on a large project. Chrome has over 20 tabs open. Crashes result in data loss.

Expected Behavior

The work itself functions normally. I can tolerate performance hiccups like STW. Software crashes, however, impose an additional burden.

Steps to Reproduce

I'm simply running a standard scheduled cleanup while operating memory-intensive software, then initiating the memory cleanup process.

App Version

3.0.0

Windows Version

Windows 10

Additional Context

No response

Checklist

• I have searched the existing issues to make sure this bug has not been reported yet.
• I have tested with the latest version of the application.

[IgorMundstein]

Thank you for taking the time to provide such a detailed and insightful report. In the six years this project has been active, you are the first user to describe this specific scenario, and your feedback is incredibly valuable. It highlights an edge case with the most aggressive cleaning function that I can now work to improve for everyone.

I want to provide a more detailed explanation of the various cleaning methods and a comprehensive workaround strategy that you can implement immediately.

Understanding the Optimization "Modes"

It's helpful to think of the different memory areas as corresponding to different levels of optimization aggressiveness.

• Safe Mode (Cache & List Management)

  This is the least disruptive mode and targets memory managed by the Windows Memory Manager itself, not memory actively held by running processes. This includes:

  • Standby List (and Standby List (low priority))
  • Modified Page List
  • System File Cache
  • Combined Page List
  • Modified File Cache
  • Registry Cache

  When you clean these areas, you are essentially telling Windows to flush its various caches. For example, the Standby List contains data left behind by closed applications that Windows keeps around "just in case." Cleaning it is very safe and simply converts that cached memory back into free memory. These actions are highly unlikely to cause any application instability because they don't directly interfere with the processes themselves.

• Aggressive Mode (Working Set Management)

  This is where the issue lies. The Working Set is the set of memory pages that a specific process has recently been using. Cleaning this area involves a direct and forceful command.

  As seen in the ComputerService.cs source file, the OptimizeWorkingSet() method iterates through all non-excluded processes and calls the EmptyWorkingSet() WinAPI function on each one. This is an explicit instruction telling applications like VS Code and Chrome, "Release any memory you aren't critically using right now."

  For a complex application in the middle of a task (like rendering a webpage or compiling code), this sudden "rug pull" can be highly disruptive, leading to the crashes and data loss you've experienced.

Recommended Workaround: A Hybrid Strategy

Instead of relying on a single configuration, I recommend a hybrid approach that gives you both safety for your automated tasks and power for when you need it manually.

Step 1: Immediately Protect Your Critical Applications

First and foremost, let's prevent any further data loss. Add your essential applications to the Process Exclusion List. This is non-negotiable for stability.

1. Open WinMemoryCleaner.
2. In the "Processes excluded from optimization" section, find and add VS Code and Chrome processes using the + button.
3. Add any other critical applications you work with.

Step 2: Configure a "Safe Mode" for Scheduled Optimization

For your 2-hour scheduled cleanups, you want them to be effective but completely non-disruptive.

1. In the "Memory Areas" section, uncheck "Working set".
2. Leave all other memory areas checked (Standby List, Modified Page List, etc.).

Your automated cleanup will now only operate in "Safe Mode." It will still free up a significant amount of cached and standby memory every two hours without ever touching your active applications, guaranteeing their stability.

Step 3: Use "Aggressive Mode" Manually and Deliberately

The "Working Set" optimization is still a very powerful tool when used correctly. I suggest you use it manually as a targeted action before you begin a memory-intensive task.

1. Before launching a demanding game, starting a large compilation, or running a virtual machine, save your work in VS Code, Chrome, and other critical applications.
2. Open WinMemoryCleaner and click the "Optimize" button with "Working set" checked.
3. Once the aggressive cleanup is complete, you will have a maximal amount of free RAM available for your next task.

This strategy puts you in full control, using the aggressive tool when it's most beneficial and relying on the safe, automated cleanup for general system maintenance.

Thank you again for bringing this to my attention. I am already planning how to refine the "Working Set" feature to be more intelligent in future updates, such as by automatically ignoring foreground applications. Your detailed report has been immensely helpful.

Please let me know if you notice any improvements after this setup.

[Jef-Z]

Hey @IgorMundstein
Thank you for your prompt and detailed explanation. I've tested this approach. The app no longer freezes or crashes. However, as you mentioned, unchecking Working set does release some memory, but overall memory usage doesn't decrease significantly. When I manually clear the Working set, memory usage immediately drops to a very low level.

I'll manually clear it when I have free time and need to slack off. Thanks Sooooo Much~

[IgorMundstein]

I am glad it worked. That's a reason why the app is customizable versus just a button to click and "make the magic." However, I will try implementing a safe mode setting that will check foreground apps opened and exclude them. That will reduce the memory optimization result, but it might create more stability.

I am unsure if you checked other user suggestions about triggers. Basically, this feature will allow you to create logic, for example, to trigger optimization when a process starts with or without delay. It might optimize your operation when you open VS Code or a browser, as in your example.

My time is just tight because I am working on indie game development in my free time.

[Jef-Z]

That's quite amazing. The safe mode and foreground app exclusion features you brought up sound very valuable. Wishing you success with your projects and thank you for your dedication to this initiative!