Sysinternals Freeware - Mark Russinovich & Bryce Cogswell

Mark's Sysinternals Blog

Polling and MSN Desktop Search

One thing I do regularly is run Filemon and Regmon to identify poorly written software. In the context of these tools a poorly written application is one that polls (repeatedly queries) the file system or Registry for changes. Polling is undesirable because it degrades performance. A thread that polls sleeps for the polling intervals, wakes up to perform its queries, and then goes back to sleep.

When the thread wakes up and the kernel schedules it the system must context-switch away from potentially useful work to the polling thread. The context switch results in an invalidation of the translation lookaside buffer (TLB – a high-speed cache of virtual to physical memory translations) of the processor and consumption of CPU resources as the thread executes. In addition, the thread references code and data as it executes, which the memory manager must make resident in physical memory, thus consuming memory resources.

If polling is so bad, what’s the alternative? If an application wants to respond in a timely manner to Registry changes it can use the RegNotifyChangeKeyValue API, and for file system changes it can use ReadDirectoryChangesW or FindFirstChangeNotification.

All that said, there are still lots of applications out there, including Microsoft applications, that poll. I suggest you run Filemon and Regmon on your own systems to see what kinds of badly-behaved software you have. Some of the most egregious offenders are the Windows services associated with major antivirus products.

When I ran Regmon yesterday the trace showed that MSN Desktop Search polls. This Regmon output shows msnlAdmin.exe, the MSN Desktop Search administrator process, repeatedly querying the current computer name value (about 4 times a second):

When I saw this I suspected that msnlAdmin.exe wasn’t polling the value directly, but instead repeatedly executing an API that reads the value. I attached to the process using Windbg (from Microsoft’s Debugging Tools for Windows), set a breakpoint on NtQueryValueKey (the native API invoked by Windows API Registry queries), and when it hit looked at the stack:

So msnlAdmin.exe is actually querying the name of the computer, which underneath results in a Registry API. The developer probably assumed that the value was cached, but since its not they should cache it. Why msnlAdmin.exe is constantly running I can’t say, however.

posted by Mark Russinovich @ 12:23 PM

Hehe, you should checkout the MS Anti Spyware program... it's worse than that!
I use Copernic Desktop Search and it works quite good. Last 1.5beta release also allows to write third-party addins , just like IFilters. The only thing that it (and most other desktop engines) lacks is a feature to search with non-English morphology.
Mark, just one question off the topic: I am curious about these additional buttons in the upper right corner - what are they for?

BTW: Don't I pool even if I use ReadDirectoryChangesW or FindFirstChangeNotification?
The buttons look like those used for multi-desktop/monitor setups, so you can send that window to the next monitor.
This is a great tip! I've written NT services before that polled or used FindFirstChangeNotification, but there's no excuse for the polling that Skype does when it's offline!

Thanks for tracking this down. We really do appreciate people looking at these things (seriously!). While we also spend time looking at what's really going on under the covers in order to improve perf, we're only human and can only look at so much in the time available. And, for the beta, we didn't have much time available for this type of investigation (which is one reason we decided to make it a beta! :-) )

In this particular case, though, since the beta we've quit using the CIState API (for some unrelated reasons), hence we aren't calling GetComputerName at all. In addition, we're being a heck of a lot smarter about what we do wrt polling vs events and, in those cases where we're forced to poll, we've taken some hard looks at how to minimize what we do there.

You should see this with the next public release of Desktop Search.

Definitely post any other "doh!" things you might find. Again, we (MSN Desktop Search devs) really do appreciate the feedback and do our best to address these things.


I'm using your utilities since early stages, and I wonder why you never released something to clean Windows Registry: what do you think about, is a Registry cleaner really needed?
Re: Dave S [msft]
Thanks for the comment, Dave. I'm looking forward to the next release. What's the best way to report other bugs that I've run into?

Re: Matro
No, Registry cleaning is uninteresting to me because it involves a thorough investigation of applications and their use of Registry data. If you're too aggressive in the cleaning you end up with broken apps. That, and the fact that Registry cruft sitting around won't be a significant contributor to Registry size or performance issues, is why I don't trust my system to Registry cleaners.
Fascinating stuff. I'm new to Regmon - so apologies if this is obvious (but I Googled briefly and could find nothing relevant) but on my PC (XP SP2), services.exe polls the registry about 500 times per second - i.e. I get around 5000 entries in Regmon if I run it for 10 seconds. Is this normal?
I sure hope the M$ people read your blog, as usual, YOU DA MAN!
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?

RSS Feed



Full Blog Index

Recent Posts

MSN Desktop Search Bugs
Updated RootkitRevealer
More on MSN Desktop Search
MSN Desktop Search
More on Google Desktop
Google Desktop


03/01/2005 - 03/31/2005
04/01/2005 - 04/30/2005
05/01/2005 - 05/31/2005
06/01/2005 - 06/30/2005
07/01/2005 - 07/31/2005
08/01/2005 - 08/31/2005
09/01/2005 - 09/30/2005
10/01/2005 - 10/31/2005
11/01/2005 - 11/30/2005
12/01/2005 - 12/31/2005
01/01/2006 - 01/31/2006
02/01/2006 - 02/28/2006
03/01/2006 - 03/31/2006
04/01/2006 - 04/30/2006
05/01/2006 - 05/31/2006
07/01/2006 - 07/31/2006

Other Blogs

Raymond Chen
Dana Epp
Aaron Margosis
Wes Miller
Larry Osterman
Bruce Schneier
Larry Seltzer