For a long long time Workshelf would frequently at start up continuously utilising 25% CPU. At the time I assumed it was caused by insufficient resources at startup as it was always resolved by restarting Workshelf. This went on for a long time, probably years. As with problems you get used to handling, I can't be sure when it 'resolved itself' but it was certainly after one or more *previous* releases of Xtreme.

The issue has resurfaced only this time with NextSTART and not only at startup. NextSTART sits there using circa 25% processor unitl you restart it. Yesterday it occurred on two occasions in addition to startup and this morning has already occurred once in addition to startup. As before, resolvable by restarting in this case NextSTART.

It is not a critical problem as my system is not processor constrained but it is obviously not desirable for one application to be permanently using 25% of processor resources for no obvious reason.

This is an initial report as at the moment I have no feel for what event is triggering the issue; I may run Sysinternals Process Monitor against to see if I can trap the event.

It may or may not be significant that NextSTART's 'sticking point' is within 1 or 2% the same as used to be the case with Workshelf.

I only recently became aware that there might be a CPU usage problem with Winstep applications on specific systems, when one user reported this issue.

I suspect that the fact that there were no more reports is, in part, because with today's multi-core CPUs the overall impact on systems is nowhere near what it would be with single core CPUs.

Unfortunately this is the type of problem that is probably the result of some very, very, specific combination of hardware/drivers/software. It's not a general problem.

As such, it is very difficult to diagnose because first a pattern must be found, i.e.; what is common to all the affected systems.

On v16.2 I added a CPU usage watchdog to WorkShelf which will fire up a red warning dialog if CPU usage is consistently above 90% for some time. This dialog makes it easier for users to report a problem (and also for them to become aware that there is, in fact, one). I already got my first report.

I was forced to do the same when, a few years back, there were scattered reports of a HUGE memory leak that ended up causing WorkShelf/Nexus to use all the available memory.

It was only through this mechanism that I managed to find out the problem had to do with dock items that had a blank Filename field as well as a blank Icon Path field. Why users left such items on the dock (not only did they not do anything as they displayed an ugly brown question mark icon) is beyond me.

As for the user who first reported the CPU usage issue, he solved it himself, before I could figure out what was causing his problem, by upgrading to another version of Windows.

Anyway, I was not aware this problem could also affect NextSTART. Good, because NextSTART is infinitely much LESS complex than WorkShelf.

SysInternal's Process Monitor and Process Explorer (with its ability to display the 'Stacked' calls of a thread) are good places to start looking.

So far all I got was that single isolated report of that CPU utilization warning. So this issue is not as wide spread as I was afraid it could be.

Did you use Process Monitor on NextSTART already? I suspect you won't find the problem there, though.

If you want to help me figure out what might be going on, use Process Explorer instead.

When you right click on a process there and select Properties, one of the tabs in the dialog that pops up is 'Threads'. From there you can see which thread is using the most CPU - selecting that thread and clicking the 'Stack' button then allows you to capture a 'snapshot' of that thread's stack at that precise moment (i.e.; what sub-routines that thread is calling).