Winstep Xtreme v26.7 (Beta 3) update went without problems.

Thanks.

Check WorkShelf's CPU usage on your system when idle... Is it a bit lower now or the same as it was before?

Min 2,3% Max 8,1%

Ok, so basically no change on your laptop's quad-core processor with no hyper-threading.

Ah well. Thanks

I'm monitoring the readings in the Task Manager.

I rarely go into the Processes tab in Task Manager but when I did just now I noticed that WorkShelf (and NextSTART) are classified by Windows 11 as "Background Processes".

This means that on CPUs with hybrid P-Cores + E-Cores (Performance vs. Efficient cores) such as the 12900K, Windows 11 might push WorkShelf and NextSTART onto a E-Core instead of a P-Core. Being classified as a “Background process” can affect the CPU usage a process gets/consumes.

So if WorkShelf is pushed to an E‑core, it will:

show higher CPU usage for the same amount of work
show slower responsiveness
show more jitter in animations and timers
show more frequent spikes
show reduced work output due to running on slower E‑cores

through no fault of its own.

I’m more and more convinced that the random prolonged high CPU usage on Windows 11 when idle was due to this together with the continuous Core Audio polling for the volume icon in the dock's tray. Both things only happen on Windows 11 systems which also explains why this was never an issue for Windows 10 users.

Ok, it is beginning to sound like I am going in circles, but this has been a really, really tough nut to crack.

Yesterday, WorkShelf suddenly went back to using 1.0-1.7% CPU while idle, completely out of nowhere.

I fired up Process Monitor to see what WorkShelf was doing. Process Monitor does not directly tell you which code is consuming CPU, but it does show the externally visible system activity generated by a process.

What I saw was a continuous flood of registry activity associated with Windows' AppModel State Repository. WorkShelf appeared to be repeatedly enumerating and resolving information for UWP and PWA applications.

This activity repeated once per second. Each burst looked like a complete refresh of WorkShelf's internal task list, with the same AppModel queries being performed again and again for every detected application.

WorkShelf's task list is activity-driven, not continuously polled.

Normally, Windows shell notifications tell it when windows are opened, closed, activated or otherwise changed, and only then is the task list refreshed. During this "storm", however, the refreshes were being triggered repeatedly despite there being no obvious activity on the desktop.

Under normal circumstances, monitoring WorkShelf with Process Monitor shows almost no activity. If the Disk Meter module is open, you may see a quick poll of the Windows Performance Counters once per second to monitor disk activity. Other than that, there is usually very little going on.

This time, I was seeing hundreds and hundreds of registry queries. Something was forcing WorkShelf to update its internal task list once per second, which in turn caused Windows to repeatedly resolve UWP information for every running UWP application - in my case, Notepad and Calculator. Each burst took approximately 69 ms to complete, so this was not an insignificant operation.

This prompted me to change the code so that UWP and PWA information resolved during previous task-list refreshes is now cached, preventing the same AppModel registry data from having to be rediscovered every time. This eliminated all of the excessive registry activity.

However, the underlying questions remain:

What was repeatedly triggering the task-list refreshes in the first place? Was the UWP application enumeration once per second truly responsible for the excessive CPU usage (I'm not putting my hand in the fire for anything else anymore, just a couple of posts ago I was genuinely convinced the Core Audio issue was the cause)? And what can be done to prevent the task list from being unnecessarily refreshed once per second if this happens again?

I have mitigated the resource usage, but I still have not fully identified the original trigger - or even established beyond doubt that the repeated UWP enumeration was the actual cause rather than merely a symptom or coincidence.

One good thing coming out of this wild goose chase is that I have been methodically identifying and eliminating unnecessary background activity and resource usage throughout WorkShelf - things such as the repeated Core Audio enumeration, tray timer continuing to fire when no tray was in use, and modules being treated as active even though their root dock, shelf or drawer was disabled.

Dear Jorge Coelho, can we leave things as they are? The program is working! And that's the key indicator!

LOL But it can always work BETTER!

Ah, I forgot to add that I deliberately applied this mitigation only to the IDE version and did not compile it into the executable, precisely in case this is the real reason behind the random, intermittent high CPU usage.

This way, when whatever causes WorkShelf to use more than 1.0% CPU happens again, I can check whether it is accompanied by the continuous task-list refresh - the symptom, not the actual cause - and then try to determine what is triggering a refresh once per second.

Once I understand the root cause, I can either work around it or eliminate it altogether.

New Betas of v26.7 (Beta 4) are out:

Winstep Xtreme beta:
https://www.winstep.net/xtreme-beta.zip

Nexus Ultimate beta:
https://www.winstep.net/ultimate-beta.zip

Nexus free beta:
https://www.winstep.net/nexus-beta.zip

This is a beta and MUST be installed ON TOP of a full v26.6 OR LATER installation. Do NOT uninstall anything first, just exit all running Winstep applications and run the beta setup file.

There is no need to backup your settings first, but it does not hurt if you do either.

###

Ok, this new beta is going to require extensive testing due to the amount of under-the-hood changes and improvements, especially in relation to how UWP apps appear in the list of running applications.

Improved performance when updating the list of running applications by caching previously resolved information, a few changes were made to how UWP apps are handled and resolved, and a bug that prevented the tasklist from reacting to applications being cloaked and uncloaked has been fixed.

This release also adds support for Vivaldi PWAs. If anyone reading this is using Vivaldi, please chime in. Also improved the handling of PWAs and how multiple sessions of the same PWA are named and appear grouped on the tasklist.

Added an option to the Auto-Hide settings on the Behavior tab to keep the tab strip stationary when collapsing or expanding a floating Shelf or Drawer.

Besides the existing docks, gridstacks and launchpads, sub-docks can now also be added to and activated from NextSTART. When adding, in the list of available sub-docks they appear marked as "sub-docks".

The NextSTART Quick Launch area now displays an animation as it expands and collapses.

Handling of multi-monitor profiles on display configuration changes has also been hardened.

Fixed modules inside Grid Stacks or nested sub-docks being incorrectly detected as active despite their root dock, shelf or drawer being disabled, preventing unused resources from being properly released.

Added new UI theme/color scheme: Dark (Midnight).



Also fixed a bug (sigh!) in the beta where the Winstep Update Manager "downloading..." window could appear either completely off-screen or not centered (depending on your screen resolution).

This happened because I accidentally dragged the window in the IDE and its startup position went from "Center Screen" to "Manual". When in manual mode the window appears at the position I have it here, and since I have a 4K monitor at 100% DPI...

I only noticed when doing some unrelated tests in the Windows 10 VM with a lower screen res and higher DPI, because here the window appeared basically where it normally would.

While fixing that I also modernized the dialog you will only see if you enable the "Prompt me before checking for new updates" setting (disabled by default).

It went from this:


to this


A bit better, IMO

have installed beta version 26.7 (beta version 4). Increased memory consumption?

Not really.

Besides, RAM usage depends on a lot of factors, what is being cached in memory, etc. Is that what you get immediately after launching WorkShelf or after some time of playing with it?

And the answer is that it is not. So the task‑list refresh was not the cause either.

With all my efforts at increasing performance, CPU usage has gotten a bit better, but WorkShelf will still go above 1% CPU usage when idle from time to time for no apparent reason. Whatever is causing this is obviously external, but damned if I know! Here is what I do know:

1. WorkShelf at idle normally uses ≤0.1% CPU.
This is with all desktop modules open, refreshing once per second, and everything else running normally.

2. For no apparent reason (usually after resuming from sleep?), it will suddenly start using >1% CPU and will stay at that level for an undetermined period of time.

3. Restarting WorkShelf does not fix it.
It immediately goes back to >1% CPU usage, so it’s not a stuck timer or anything malfunctioning inside the WorkShelf process itself.

4. Process Monitor shows nothing that explains the “heavy” CPU usage.
In previous cases it did reveal things that helped me improve performance and make the application as lean as possible, but none of that was related to this issue. Still, some good is coming out of this wild goose chase lol.

5. Now here’s the weird part:
If I close all desktop modules, CPU usage drops from, say, 1.2% to 0.7%.
So just removing the module refresh accounts for a 0.5% difference.
Why is this weird? Because when CPU usage is normal, total usage is around 0.1%, meaning the module refresh uses far, far, less than 0.1%.
How does that suddenly jump to a 0.5% difference?!
It’s almost as if WorkShelf’s CPU usage is being reported as x10 of what it really is for a while.

6. Running WorkShelf under the IDE shows nothing abnormal and CPU usage for the IDE remains low.

7. Running Nexus Ultimate at the same time (same codebase, no desktop modules) results in ≤1% CPU usage, just like WorkShelf when everything is normal.
This makes it seem like whatever is causing this is actually targeting WorkShelf.exe.


I still think the culprit and the reason it only happens with Windows 11 and not Windows 10 has to do with Windows 11 support for P-Cores and E-Cores on modern Intel processors.

A slower E-core takes longer to perform the same amount of WorkShelf work. Suppose the once-per-second module refresh requires:

1 ms on a P-core
5 ms on an E-core

The actual work is unchanged, but the process accumulates five times as much processor execution time. A time-based CPU counter would therefore report roughly five times the CPU usage. Microsoft explicitly distinguishes time-based counters, which measure how long a processor is busy, from “utility” counters that attempt to normalize for processor performance.

This fits my observations unusually well:

WorkShelf normally uses about 0.1%.
It occasionally jumps to roughly 1%.
Ordinary recurring operations, such as refreshing desktop modules, become disproportionately expensive.
Restarting WorkShelf does not help because Windows schedules the new process similarly.
It often happens after sleep, when scheduler, power-management or processor-QoS state may have changed.
Nexus Ultimate may remain unaffected because its process gets a different scheduling classification, foreground history, power-throttling state or core placement.

The module result makes particular sense under this theory. Closing the modules saves 0.5% not because they suddenly do more work, but because each module update takes substantially longer while running on an E-core.