Ok, as I suspected, this issue has nothing to do with the old Multi-Media timer issue.
Luckily I managed to reproduce the problem on my laptop (I never send it to hibernation, just to sleep, so I had never run into this before). After further investigation, it turns out that the culprit is actually not Winstep Xtreme at all.
From Vista onwards, applications were no longer able to perform specific actions that required administrator rights, even if the user was running as an administrator of the machine. In order to do that, an application must run elevated, which, among other things, brings up the dreaded UAC prompt.
But running elevated has other problems: for instance, an elevated application is not able to accept drag & drop operations from non-elevated applications (such as Explorer). Since Winstep Xtreme relies heavilly on drag & drop operations between Explorer and Xtreme to add shortcuts to docks, etc..., running it elevated is not a solution (in fact, Xtreme will complain if you try to run it elevated).
On the other hand, due to its nature, Xtreme has to be able to do things that do require admin privileges (for instance, installing theme fonts, changing the system time, etc...)
The solution was creating a service, WsxService.exe, which launches automatically at startup, runs with admin rights, and performs all the operations requiring admin rights on request from the other Winstep applications.
This service is also used by WorkShelf to get the names of elevated processes(again, a non-elevated application would not have access to this) in order to display them in the CPU Meter, for instance. Without this service, the CPU Meter and, for instance, the running application indicators, would be unable to detect when specific elevated applications are running.
WorkShelf communicates with this service once per second, through the Windows Service Control Manager and the ControlService() API. There is, however, one major snag with the SCM. From the MSDN:
"The SCM processes service control notifications in a serial fashion, it will wait for one service to complete processing a service control notification before sending the next one. Because of this, a call to ControlService()
will block for 30 seconds if ***any*** service is busy handling a control code."
Note the 'ANY' service. When Windows returns from hibernation, several services will resume communicating with associated hardware. Sometimes this takes time as the hardware must come back online and the associated service will 'hang' until it does (or until it times out). As you've read above, all it takes is *one* service hanging, even temporarily, for all the other services to hang as well for up to 30 seconds.
After 30 seconds you do get a time-out, but you might hang again for another 30 seconds the next time you try to communicate with your own service. Not because there is a bug in your code or in your service, mind you, but because SOME OTHER SERVICE, which you have no control upon, is currently busy.
Thus you get a weird behavior in which the app might work for one second, hang for 30 seconds, work for another second, hang again for 30 seconds and so on until the SCM gives up on the busy service or the 3rd party service resumes working properly.
So, you guys thought doing these things was easy, heh?
I would almost be willing to bet, Deovox, that now that you know this you will also notice that WorkShelf will resume working properly immediately after you hear the sound of a new Plug & Play device being added/detected on your notebook.
Posted: Sun Jul 04, 2010 4:31 am 
