First they should solve all the issues in 24H2, but I suspect they won't lol

I will have to make a post detailing stuff wrong with 24H2 that affects Winstep software. I have never seen such a train wreck, and this *months* after launch!

Another apparent issue: something as basic as auto-hiding the **Windows** taskbar doesn't seem to be working (not good because it means in certain cases a collapsed shelf docked to the bottom of the screen becomes inaccessible, as it is covered up by a Windows taskbar that should be hidden but isn't - also not good if you are trying to avoid burn in on OLED displays).

I searched online and the "official" solution for this seems to be to restart Explorer via Task Manager (which comes with its own set of issues as some applications will not re-register their system tray icons etc) and is, at best, a temporary solution.

OTOH, the issue that affected incorrect CPU usage reporting in all 3rd party applications that has been plaguing us since 22H2 (which I provided an optional fix in the CPU Meter Settings via the 'Serialize Timer Expiration' setting) SEEMS to have been fixed. Only took them 2 years and two major Window releases, yay!

Another record for Microsoft lol

Anyway, I haven't run into any high memory usage situations with WorkShelf/Nexus Ultimate yet as those reported in this thread, and memory usage numbers seem to be stable. What this probably means is that whatever is leaking memory is probably specific to some configuration users have (i.e. to be clear: the memory leak is not the fault of the Winstep application itself but another bug in the OS, but for it to happen it requires a specific configuration in the Winstep application - or even in Windows itself - which I will need to reproduce here in order to find the culprit and come up with a work-around).

Unless Microsoft fixed this issue in one of the latest updates to 24H2, of course. I need more feedback from Winstep users on 24H2, please.

Forgot to add another MAJOR issue with 24H2: docks, desktop modules, the NextSTART taskbar, etc, are no longer able to remain on screen if the user presses WIN + D even when the "Keep x visible when pressing WIN+D (Show Desktop)" setting is checked. This is NOT specific to Winstep applications, it affects **ALL** 3rd party applications that relied on keeping some of their windows visible after pressing WIN+D (like Rainmeter, Objectdock, etc).

Windows with the WS_EX_TOOLWINDOW extended style would remain on screen even when WIN+D was pressed, so if you wanted a screen object (such as a widget, etc) not to be automatically hidden by Windows, you would simply set this extended style in the screen object. It has been like this, since, well, forever.

24H2 broke this. I'm not sure if it's a bug or if it was deliberate and Microsoft in their infinite arrogance simply doesn't care, but it is affecting a ton of applications that relied on this behavior and, of course, pissing off a lot of users since currently there is no work-around that properly preserves the z-order of the windows, etc...

Personally I never use WIN+D, but I'm pretty sure I would be pissed too if I did and it no longer worked as expected with my favorite applications.

It just saddens me to see Microsoft being run by a new generation of developers who thinks new is always better and doesn't understand why backwards compatibility is so important. If Windows wasn't such a monopoly in practice, I'm pretty sure MS would quickly get the message as soon as users started voting with their feet and moving en masse to other OSs.

Just installed the latest 24H2. Nothing has changed for me on high CPU use. I reset settings, no difference. I did see a significant drop when disabling the workshelf docks I had enabled. But maybe that is supposed to happen?.