Thanks for reporting this, but it's not a bug... it's a feature!!!
Seriously, that's just WorkShelf polling the Internet for the information required by the several Internet related modules and functions (weather conditions, atomic clock synch, new email messages, online fortune cookie retrieval and info about application updates).
WorkShelf is not *really* hogging the CPU in detriment of other applications, it just seems that way due to what is really happening: WorkShelf is in a tight loop waiting for a response from an Internet server. For every passage in this loop, WorkShelf checks to see if the Internet server has responded. If it has not, then WorkShelf yields the CPU to other applications through a DoEvents instruction. As soon as Windows has finished with whatever the other applications are doing, it returns control to the instruction after DoEvents. So, in effect, WorkShelf is not stealing time from other applications, it is actually allowing them to run more often, but in the process it also uses whatever processing power is left.
And the keyword here is 'processing power left'. For instance, load a theme where the desktop CPU module allows you to see a list of the applications using most of the CPU. Now tell WorkShelf to check the Atomic Clock. You should see CPU usage immediately jump to 100%, with WorkShelf taking up the most of it. Now run some CPU intensive task on another program and you will notice that as the CPU percentage used by this task goes up, the CPU percentage used by WorkShelf goes proportionally down.
And since the proof is in the puddin, WorkShelf is clearly NOT hogging the CPU because all other applications continue to run unhindered and your system remains 100% responsive... Something that would not happen otherwise.
I do have to add this to the FAQ one day. Or, better yet, re-write the code so that yielding the CPU via DoEvents is no longer necessary (although that would be a lot of work just to prevent WorkShelf from
appearing to be hogging the CPU).