App interference detected affecting power settings (CPU usage at 100%).
App interference detected affecting power settings (CPU usage at 100%).
Hey everyone, I’m dealing with a problem where the IDLEDISABLE setting in my power configuration gets accidentally changed by an unknown application. To give you a clearer picture: This feature controls whether the CPU stays idle—essentially keeping it busy at 100% load—even though the actual workload should be lower. In reality, the task manager and process load calculations show a much lighter burden. It’s been a recurring issue with certain software or odd configurations that reset this setting each time I log in or start an app. It’s definitely annoying, but there are ways to handle it.
I’ve tried putting a quick script on a batch file to reset the IDLEDISABLE value back to its default. Initially, I just ran it manually when I noticed the problem, and later scheduled it every few minutes. That helped for a while, but now with recent driver updates for RAZER, NVIDIA, AMD, and more, the problem has returned stronger than before.
The IDLEDISABLE can jump randomly between 0 and 1, sometimes briefly spiking CPU usage or staying stuck at 1 indefinitely. If you’re curious about which apps might be affecting this, you can check PowerCfg with specific queries in PowerShell.
So far, the two main paths are:
1) Figure out which software or driver is causing the change and block it if possible.
2) Prevent system-wide overwrites by adjusting group policies or settings.
I’m open to any tips on monitoring app behavior or restricting power settings so apps can still function without disrupting my system. Thanks for your help, Alex!
It appears there is a mismatch between the registry key and its corresponding value in the PowerSettings file. While the registry entries remain unchanged despite checking the powercfg output and refreshing them, the actual settings in the file don't update accordingly. Adjusting the attributes to zero didn't resolve the issue.
Just to confirm—I’m okay with zero applications altering the IDLEDISABLE state. It’s an edge case, and it could make sense in high-performance computing for skipping certain CPU states. For regular desktops, though, it’s mostly irrelevant unless you’re into wasting energy. I still don’t understand why any program would bother using this feature.
It appears the issue was caused by MSI Dragon(/Creator) Center: MSI.CentralServer.exe. Share the findings with others experiencing similar problems. For those using the German version, open the Event Viewer and look for entries under "Windows-Protocol" -> "System". Check if you see messages from "UserModePowerService". You might need to enable debug or analytics options in the view menu. There, you can track when processes switch between profiles, especially noting the reload after setting the IDLEDISABLE state. After stopping the service, the state remained consistent, indicating the problem was resolved.