Has anyone tried workshelf on the upcoming 24H2?. I tried it early last month, and it was using a high amount of CPU. Just wondered if the newer builds are better. Is there a planned update for 24H2. Many thanks.

First, running preview versions of Windows almost always guarantees problems, second, you don't really get no support because software companies are not going to waste time trying to fix an issue that is actually related to Windows itself and not their software.

This said, you need to provide more details. Why do you say WorkShelf is using a high amount of CPU? Define "high amount of CPU" (how many cores does your CPU have, what percentage of CPU is WorkShelf using, what software are you using to measure WorkShelf's CPU usage) ?

Have you already tried setting WorkShelf settings to default after (of course) backing up your current settings first in WorkShelf Preferences -> Advanced tab -> Backup) ?

Is the high CPU usage, as you described it, a constant (i.e. while idle) or only when performing certain actions?

Again, please provide as many details as possible (and screenshots too if you want). So far nobody else has complained, let's see if anyone else also running 24H2 says something.

Late to the party but been tracking a number of issues with Nexus on Windows 24H2 (I have the paid Nexus Ultimate version).

1. As above, on 24H2, occasionally Winstep will start using a large amount of CPU power. Sometimes it only does it for a few seconds, other times it will stay that way till you either reboot or restart the program. I've seen it go as high as 10-15% when it's usually only 1 or 2% for a second then nothing.

I have 6 cores (12 threads) and normal usage is anywhere from 0 to 2% and it does this when you're not even using Nexus. It's like the program is getting caught in some kind of loop trying to update the dock or something in the background whether you are using it at that moment or not.

Can't make a screenshot of it due to the below:

2. I've actually had to stop using the program entirely due to it crashing my machine. It's not entirely the programs fault, there's something fucked up with Gigabyte's bios versions that are causing issues and so far I can't track down the issue, but trying to run Nexus actually makes it crash more.

I've solved the main problem by simply disabling 1 thread on my system. No idea why that works, but it seems something in the bios is getting confused and mixing up memory allocations then the kernel crashes due to fast eresource errors, irq related stuff or things accessing files at the wrong privilege level. Mostly it all traces back to various memory errors or access violations.

But..... I've tested every hardware component in my system and it's all fine, CPU, ram, drives, MB etc, all have been tested and proven to be working and in some cases swapped to a different machine which has no issues with the hardware. Matter of fact, running stress tests or playing a full screen game is fine, the system will work perfectly, it's only when it's under little to no load that it crashes (like surfing the web, watching a video or just sitting idle at the desktop).

Disabling 1 thread seems to have fixed the issue (I've had it come and go for over a year now so I'm 99% sure that the root cause is a bios issue I just can't pin it down to the specific cause).

However if I run Nexus the machine will crash in a minute or less. Same happens if I run crystaldisk monitor.

No idea why Nexus would make the problem worse. I'm not 100% sure it's Nexus itself, it may be more related to the Winstep Helper Program (which I had to disable as well).

I have the additional problem of it won't run without VBScript installed and while I don't mind reinstalling it if I absolutely have to the fact is MS has deprecated VBScript in favor of JavaScript and PowerShell so anything in the program that runs on VBScript really should be ported over soon or nobody is going to be able to use the program anymore hehe.

If I have time over the weekend I might take another stab at it and get some screenshots if the machine will stay running long enough but I doubt it will.

I do have 1 screenshot I'll attach here that shows a memory error. That's one of only 2 times when Nexus crashed without taking down the whole system and actually showed an error message.

It sounds like it might possibly be due to a link/s pointing to a network drive?

Don't have any network drives though. I have an NVME as the main drive, then a sata SSD for backup system images. Then 2 X 2TB mechanical drives for long term storage and extra backups. The only network I am connected to is my wifi and there's no storage drives attached to that.

Looks to me like Microsoft really did a good job (NOT!) on Windows 11 24H2. This is obviously not a problem with Nexus but with the OS itself (or some kind of hardware problem, if you had not mentioned 6 cores I would have suspected a faulty 13900K/14900K CPU, which degrade over time).

yeah i have 6 cores also. The same activity as whmxtra mentioned. idle it jumps up to 15% cpu. I was just checking to see if it had any issues, so i knew ahead of its launch. I'm back running 23H2 which is down at 1-3%. The initial post was too see if anyone else had issues, not asking for support, as i know its not released as yet. I do use the paid for version as well, purchased it over many years.

Could also be an issue with the way the OS is reporting CPU usage (not the crashes experienced by whmxtra, of course, that is something else entirely).

22H2 made some under-the-hood core changes that broke CPU usage reporting for many "legacy" (with double quotes) applications, which suddenly started reporting incorrect/too little CPU usage. Microsoft doesn't seem to care AT ALL, even after all this time. It's possible they made further changes related to this in 24H2.

The Winstep CPU Meter module has an option that fixes the 22H2 issue in the CPU settings panel (setting Serialize Timer Expiration to Off), but it has a global effect on the OS.

Well it would seem this time instead of cpu reporting issues it's having memory reporting issues. Like it looks for things in the wrong spot or (more likely) the stuff gets moved and not reported back to the app what the new location is. So something is off in terms of memory management but the memory controllers are fine as is the ram I'm using (tested and verified working in another machine as well as swapped for another kit to make sure).

It's definitely not a Nexus specific issue or a fault with the program. I can reproduce the crashing by running something like crystaldiskinfo as well. And it's not a CPU fault either as I can put my CPU in another machine and it's fine. Not the motherboard either, at least not something "broken".

I know it's related to something in the bios or AMD's Agesa as I've had the problem go away on certain bios versions (which mysteriously gigabyte has pulled those versions from it's site and only the broken versions are left).

But I also know that the winstep helper program triggers the crash more frequently, I can start the helper service without nexus even running and it'll trigger the crash.

What I'm trying to figure out is what the helper service actually does and what parts of windows it communicates with in order to pinpoint what is triggering it. Weirdly Nexus seems to run just fine without the helper service running (still crashes the system but only once in awhile, not regularly).

So it's gotta be something in the helper service triggering it and if I can figure out what that is I can figure out a proper fix for the issue. Is there a specific windows library it uses? Like maybe a specific version of the c++ runtimes?

I can make my system stable by simply turning 1 thread off (although nexus and crystaldiskinfo will still crash it if I run them but without them it only crashes maybe once every day or two).

I have some notion that something is going wrong with the infinity fabric or the timing of something (not the ram timing as I've tried lowering timings and speeds and increasing them and neither changes anything).

I also suspect it's specific to AMD for some reason. But if I can find the right starting point it'll be fairly easy to figure out what it is. Problem is windows is absolutely useless in providing any usable info about it. Just says the kernal crashed or various standard errors that would normally indicate hardware issues but in my case I know for a fact the hardware is fine so windows logs and dump files etc just don't provide the info I need.

Not specific to windows 11 either, the problem happens on windows 10 as well so it's not OS specific (which makes it even harder to troubleshoot).

Quick question, which CPU do you use? I'm using an AMD ryzen 5 3600. Also what motherboard (mine is a cheap gigabyte b450). I'm reasonably sure it's gigabytes bios causing my issues as I've had bios versions that make the machine perfectly stable with no issues. Sadly those versions are beta versions and they have removed most of them from their site and refuse to give me a download link while the current beta and stable versions have the crashing problem.

The Winstep Helper service, just like the description of the service states, is used by the main Winstep application for actions that require elevated/admin privileges to perform (for instance, adjusting the system time with the atomic time server clocks, installing fonts, getting CPU/memory usage information from other elevated processes so these can be displayed in the CPU/RAM meter modules, etc).

The main Winstep application should NEVER be run with admin privileges (and you will get a prompt warning you of this if you try) since it is mostly a program launcher and anything launched from an elevated application runs itself elevated too. So HUGE security risk, an absolute NO-NO.

This is why the Winstep Helper service was added back in the Windows Vista days when Microsoft tightened security in relation to XP (under XP everyone ran everything with admin rights).

The main Winstep application runs "just fine" without the helper service because it will detect the service is not running and adapt accordingly, but it will be unable to do any of the things described above that require admin rights (and therefore some information might be missing or incorrect because, for instance, a non elevated process cannot get certain types of information from elevated processes and a newly installed theme might not look as intended because the font used by the theme designer could not be installed, etc)

Thing is, the helper service ONLY does something when directly requested by the main Winstep application via special commands issued through the Windows Services API - otherwise it is just an idle process waiting for those commands.

So, if the helper application is crashing even when the main Winstep application is not running, this means something is inherently wrong with the actual OS (or there is some kind of hardware fault that is causing random corruption/crashes).

P.S. You might also want to check if "Core Isolation" aka "Memory Integrity" is enabled in the Device Security settings of Windows and see if turning it off solves anything or not.

Core isolation is off, I never use it due to about 1000 problems it can cause hehe. And yes I know not to run programs with elevated privs hehe.

I don't use the CPU/ram meter modules. Only one I do use is the weather one and I don't use the clock module either although the weather mod probably does use a hidden clock to determine when to update the module.

But I'm starting to get a sense of things here. It's "requesting" elevated permissions to access something but not actually being granted those permissions so the kernel craps out thinking something is wrong. That would track with crystaldiskinfo also causing the crashing since it would need elevated privileges to access the disk related info. That would fit perfectly with the error messages and crash dump info as they all point to some version of something trying to access something at the wrong privilege level or some variation of that.

But it's not the OS, the issue persists across win10 and win11 and all regular/insider versions in between. I did not go further back for obvious security reasons. I also tried linux and had similar errors with equally useless logs that just blame it on a driver error when it's not the root cause.

It's also not hardware related as I have tested/swapped every bit of hardware in every way possible. And I'm not an "enthusiast". I have around 35 years of building and fixing PC's so trust me when I say the hardware has been fully checked and is functioning. Been doing this a long time and I know all the steps to eliminate hardware as the issue (although 99% of the time the hardware is actually the problem hehe).

But this again brings me back to the BIOS... the versions that "worked" on my system and stopped the crashing all had some modifications that prevented the use of secure boot. The ones that DO crash the system have secure boot enabled (in the non secure boot versions gigabyte locked them down to setup mode rather than user mode).

But disabling secure boot doesn't change anything either so it's not specifically secure boot but something related to it that gigabyte is messing with but not documenting anywhere.

But now I have a starting point to start to narrow it down. Everything in windows and even linux just kept pointing to a buggy unnamed driver or a memory issue, both of which I know aren't the cause.

So it's something with regard to the granting of elevated privileges that is somehow getting blocked at the bios level (not at the os level, I have already experimented with that part of things).

So next step for me is going to be diving into the bios and manually tweaking some settings till I find the part that is blocking the privs from being granted properly.

Thanks for the help, now at least I know "where" to dig rather than randomly digging a hole to China hoping I get lucky somewhere along the way hehe.

Although it doesn't explain why disabling 1 single thread seems to make the system more stable though. That might just be dumb random luck. Although it could be related to how the info is routed due to preferred cores. The core I disabled the thread on is the fastest core on that side of the die so it gets used a lot. Possibly disabling the hyperthread on that core forced it to go a different route through one of the other cores. But that would indicated a CPU issue but there isn't one, I've even put this CPU into another computer and it ran perfectly fine. Also passes stress testing and works fine when gaming etc.

But that's 2 things for me to look into when I have a chance, secure boot adjacent items and preferred cores stuff as well. 1 or maybe even the combo of both is what is causing the issues but at least I know where to look now.

Are you sure memory is not the cause? There is a RAM setting in the BIOS that NO memory testing software will catch, but it will randomly crash your system and even silently corrupt your OS.

IIRC, it's tRFC (memory refresh cycle) being too low or too high. Don't ask how I know.

I'll take a look for that when I have a chance but odds are it's fine.

Ram has been tested thoroughly and even tried 1 slot at a time. Also swapped to a different ram kit. Also put both those ram kits in another computer and there's no issues with them running in those machines. I've also tried with XMP both on and off and manually lowered timings (max ram speed for my CPU is 3600 Mhz which is what I normally run at but I've tried going to 3200 and even the default non XMP speeds).

If it was a timing issue (or refresh issue) it would come up under any circumstances. But if I run a full screen game or I run stress tests etc it works perfectly. I literally ran OCCT for an entire day with no errors reported with anything.

I will double check all the memory settings but I haven't changed anything other than turning XMP on or off or manually lowering the multiplier a few times. Usually its "auto" settings work just fine.

And it wouldn't explain why the problem went away for about a month till I updated the bios (still don't know how I didn't keep a copy of that bios and the issue with the new bios didn't appear for several days, during which nothing was changed on the system at all).

Actually nothing changed between when I originally had the problem, then the problem going away, then the problem coming back. Only thing I did with the system in that entire time was update the bios (didn't even update windows as the insider channel I'm on wasn't getting updates at that time).

But it never hurts to check. Maybe I missed some new bios setting or accidentally changed something without realizing it.

There's definitely something wrong with how the OS is communicating with the ram in terms of privileges etc. Although I did just update windows today finally to the latest 24H2 version in my channel but now I've had weirder errors with direct x rather than the usual memory errors. See how useful windows is lol. I suspect it was just a bug in that case but keeping an eye on everything else.

I do think it's somehow related to secure boot because the version that worked ok had secure boot locked down into setup mode and new bios doesn't. But turning secure boot off doesn't fix the problem so it's something connected to secure boot but no real indication of what that connected part is. Not a lot of options with secure boot that I could test or change. It's basically on or off (although I could try resetting the keys).

Getting closer at least. In reality I should just throw another board in and be done with it but I've never failed to figure out a problem in all my years and pride won't let me give up on this one lol.