[BUG] High CPU usage even when idle #827

Activity

1. DerDemystifier

   added

   bugSomething isn't workingSomething isn't working

   on May 22, 2026
2. unchihugo commented on May 23, 2026

   

   unchihugo

   on May 23, 2026

   Owner

   More actions

   Hi @DerDemystifier, thanks for reporting. Do you still notice this behavior? If yes, could you list your computer specifications?
3. DerDemystifier commented on May 23, 2026

   

   DerDemystifier

   on May 23, 2026

   Last edited by DerDemystifier

   Author

   More actions

   Processor	AMD Ryzen 5 5600GT
   System type	64-bit operating system
   

   I’ve figured out how to reproduce the problem—it happens when I press the media buttons. For instance, you can trigger the media track keypress in PowerShell if you don’t have it, and watch Task Manager; it will spike and stay at the top.

   (New-Object -ComObject WScript.Shell).SendKeys([char]176)
4. unchihugo commented on May 23, 2026

   

   unchihugo

   on May 23, 2026

   Owner

   More actions

   Thanks for the information. Does CPU usage still spike if FluentFlyout is closed? If it doesn't, could you try disabling the media flyout to see if the CPU usage is still high then?
5. DerDemystifier commented on May 29, 2026

   

   DerDemystifier

   on May 29, 2026

   Last edited by DerDemystifier

   Author

   More actions

   Disabling the media flyout doesn’t immediately stop the CPU usage spike. It only drops after I press a media key AFTER disabling the media flyout.

   I reckon it has something to do with the media flyout, but it could be some kind of process that persists even after the media flyout slides down.

   Is there a logging system in the app? It might be helpful to track metrics alongside events to pinpoint exactly when things went wrong.

   I must add that the bug is not reproducible 100% of the time. I only notice it when CoreTemp triggers the overheat protection balloon popup.
6. github-actions commented on Sep 3, 2026

   

   github-actionsbot

   on Sep 3, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue has been inactive for a long time. If it is still relevant, please leave a comment to keep it open.
7. github-actions

   added

   staleIssues & Pull Requests without any activityIssues & Pull Requests without any activity

   on Sep 3, 2026
8. lgc2333 commented on Sep 8, 2026

   

   lgc2333

   on Sep 8, 2026

   Last edited by lgc2333

   Contributor

   More actions

   please do not stale this issue

   startup
   

   pressed media key (pause/resume) and it keeps ~8% usage (i5-10400F)
   
9. DerDemystifier commented on Sep 8, 2026

   

   DerDemystifier

   on Sep 8, 2026

   Last edited by DerDemystifier

   Author

   More actions

   Try resetting the settings; if I remember right, that fixed the issue for me. I also kept tweaking the default settings to a minimum, and I haven’t had this problem since.

   For a true fix, I think a better logging and monitoring needs to be implemented to better investigate performance issues like these.
10. lgc2333 commented on Sep 8, 2026

    

    lgc2333

    on Sep 8, 2026

    Contributor

    More actions

    Reproduced this locally. Sustained 5-8% CPU happens when the taskbar's UIA tree is in a slow state (e.g. during auto-hide taskbar transitions); a CPU trace shows the hot frames are exactly the widget's UIA walk - AutomationElement.FindFirst, ProxyProviderFromHwnd, HwndProxyElementProvider.GetFirstChild, Accessible.GetChildren, WindowsRebar.GetFirstChild - plus Wait()-blocked UI thread timeouts (matches the Timeout querying taskbar XAML element: WidgetsButton warning in my logs).

    Draft fix: #1117 - non-blocking background queries with a 3s cache and proportional backoff when the walk is slow. Verified under the same stress: no sustained CPU, no timeouts.
11. lgc2333

    added a commit that references this issue on Sep 8, 2026

    fix: taskbar widget UIA polling causes high CPU (Closes unchihugo#827)

    ...

    This issue will close once commit 9847a09 is merged into the 'master' branch.

    9847a09
12. lgc2333 commented on Sep 8, 2026

    

    lgc2333

    on Sep 8, 2026

    Last edited by lgc2333

    Contributor

    More actions

    I'm unsure this PR can fix this issue. Did you enabled taskbar widget and auto hide taskbar? @DerDemystifier
13. DerDemystifier commented on Sep 8, 2026

    

    DerDemystifier

    on Sep 8, 2026

    Last edited by DerDemystifier

    Author

    More actions

    I don't use the auto-hide taskbar feature and only enabled the taskbar widget once when first testing the app. It had the acknowledged width and clipping issues with the tray icons, so I disabled it, it wasn't enabled when I was having the High CPU usage issue. After the reset, I never enabled it after.

    I can no longer reproduce the issue (unfortunately) with the media keys or otherwise.

    Here's an export of my current settings.
    FluentFlyout_Settings_2026-09-08_16-06-57.xml
14. github-actions

    removed

    staleIssues & Pull Requests without any activityIssues & Pull Requests without any activity

    on Sep 8, 2026
15. lgc2333 commented on Sep 9, 2026

    

    lgc2333

    on Sep 9, 2026

    Contributor

    More actions

    Correction to my earlier analysis: the cause is not taskbar widget UIA polling. I reproduced this and captured a CPU trace while it was happening.

    Trace (12 logical cores, ~8% = one core):

    13.87% excl  VolumeMixerWindow.HideVolumeOsd()
      Thread 0x9AC  CPU_TIME
        FluentFlyout!VolumeMixerWindow.HideVolumeOsd()
        FluentFlyout!VolumeMixerWindow+<>c.<ShowFlyout>b__16_0()
    

    HideVolumeOsd() runs on thread-pool threads started from ShowFlyout(). Two were spinning at capture time and still spinning when the trace ended.

    Cause. It enumerates XamlExplorerHostIslandWindow windows like this:

    while ((hwndXamlIsland = FindWindowEx(IntPtr.Zero, IntPtr.Zero, "XamlExplorerHostIslandWindow", null)) != IntPtr.Zero)

    Both handle arguments are NULL, so FindWindowEx returns the same first island every time and the body re-processes that one window forever. None of the three continue paths advances the cursor. When the first island is not the volume OSD (its InputSite window has a zero-size rect), the loop never exits.

    Why it matches your report. The keyboard hook calls volumeMixerWindow?.ShowFlyout() on every media/volume key when VolumeControlEnabled is set, so it starts on the first key press and persists; it does not need the taskbar widget. More key presses stack more spinning threads.

    Fix: #1122 — pass the previous handle as hwndChildAfter so enumeration walks the islands and terminates, matching the upstream gpkgpk/HideVolumeOSD code the port was based on.

    Before/after on one zero-rect island: the old loop hit 383,621 iterations in 5s without exiting; the fixed loop exits in one iteration and logs OSD window not found. With the fix, 20 volume keys leave CPU at 0% (was 8-9.5% sustained).

    👍React with 👍1Reacted by Bassim El Bakkali El Gazuani
16. DerDemystifier commented on Sep 18, 2026

    

    DerDemystifier

    on Sep 18, 2026

    Author

    More actions

    

    It does look like the issue originates from the FindWindowEx loop, and I think fix #1122 is right on target. Hopefully, @unchihugo merges it soon!
17. unchihugo

    closed this as completedin #1122on Sep 22, 2026