Auto-suspend process when it doesn't have focus (while system is on battery)

[jdorseywx]

Many apps consume a lot of power while "idle" in the background (Chrome, Visual Studio to name a few), thus draining the battery quickly. When on battery, I often use pssuspend (sysinternals tool) to suspend a process, but then I'm forced to suspend/resume apps that I want to temporarily use.

Request is for a PowerToys option to automatically suspend a process when it doesn't have focus (or after a configurable timeout), then resume that app when focus returns (e.g. via mouse click or alt-tab). This option would be in effect when the system is on battery power, not plugged in. May also need a whitelist of apps that can be suspended, e.g. you may not want some apps suspended ever (Slack, etc.). Thanks!

[ghost]

That's going to be cool, it's gonna double or even triple your battery life.
Better if there're more customizations, such as :
1.resuming a process for 5 seconds every 1 minute for specified processes to make sure they can receive new messages or work correctly (this should be customizable),
2.an option for whether process should be suspended only when it's minimized,
3.only suspend a process if its cpu time is less than XX.
4.have multiple plans like what power plans does, such as uses plan A when not plugged in and plan B when in battery saver mode.
those make win32 apps more suitable for portable devices, especially when you have your power adapter left at home.
BTW you can use Resource Monitor to suspend/resume a process.

[indierawk2k2]

These are all great suggestions for a "Power" Power Toy. :)

[rcmaehl]

I've actually got a proof of concept application I was developing before I found this suggestion existed.

From tests, if a process is suspended the window doesn't become active, even through Alt-Tab, taskbar, etc. So you'd have to completely work around this somehow. Maybe detecting when the mouse button is clicked on a window? It's no easy fix.

Additionally, there's the concern for custom hardware. Stuff like Corsair hotkeys, and even function buttons on Microsoft's own Multimedia 4000 keyboard stop working. I had to create exclusions for these.

Finally, it'd probably be best to create a blacklist instead of a whitelist if implemented as a powertoy, not just for the previous concern, but in general. Without knowing what the user is going to be using it with and for it's incredibly user-unfriendly to just suspend a process. #146 is a good starting point however.

Regardless, it is a great idea for a powertoy that MS devs can probably do better than myself. Here's the results from my proof of concept on an Intel Atom x5-Z8550:

[crutkas]

On discussing this, the reason we cannot suspend arbitrary Win32 apps is because they are not isolated from one another (all full trust); they share named objects, can access same files without broker, free window messaging, etc. One example is if you suspend an app that is holding a file open. With UWP, we can find the app that has it and shut it down (it has saved state). With Win32, if you caught the app at the wrong time (opened the file and hasn’t closed yet), the foreground app will fail to get access to the file.

if you suspend something with sysinternals, you're putting your system at risk for instability

[AJolly]

I'd be interested, even if it does put my system at risk.