Applet Mitigations

As I’ve mentioned, applets  can be a plague on your system.  The annoying thing is that it’s possible to write applets that aren’t so horrible.  And most of the mitigations are really just common sense ideas – there’s nothing spectacularly complicated in any of them.

As with the earlier posts in this series, some of the mitigations are common to all types of applets (and all applications in general), and others are specific to various types of applet.


Let’s start with the basics…

For applets that run all the time:

Do you REALLY need to have an applet running all the time?  The best applet is one that doesn’t run at all.  Is it possible to bundle your applet’s functionality into an application that the user invokes?  The start menu highlights newly installed applications, so your new application will be visible there, worst case there are other mechanisms for installing your application in locations that are visible to the user (the desktop is one of them (although that has its own set of issues)).

Now that you’ve decided you need an applet that runs all the time, please reconsider.  Seriously.  I know I just asked you to think about it, but really.  Steve Ballmer says that sometime in 2008, a billion people will be running some version of Windows, that’s a LOT of people.  If your product is successful, you’re likely to be selling to a couple of million of them – do you believe that your applet provides enough value to every one of those customers that you need to have it running in their face?  Really?

Once you’ve decided that you REALLY need to have an applet running, make sure that there’s a way for the user to turn it off.  There’s nothing more annoying than realizing that the software that came with some random piece of hardware that I use maybe once or twice a month is running all the time on my machine.

If you’ve written an applet because you want to let the user know about some cool feature, why not use the RunOnce key to let the user know about the feature, letting them know how to discover the feature later on, then shut up and never bother them again?


For all applets (and all applications that are expected to run all the time):

Think about how to reduce the applets impact on the user.  Reduce the DLL load in your applet whenever possible – each DLL you load consumes a minimum of 4 private pages (16K on x86) and takes between 500K and 1M cycles to load.  Anything you can do to reduce that is better. If you can get away with just loading kernel32.dll and the C runtime library, it’s better.  Consider delay loading DLLs that you infrequently use.

Reduce the stack size used for the threads in your applet – by default Windows threads get a 1M commitment and 10K of reserve (which really turns into 12K of reserve due to paging).  That means that every thread is guaranteed to consume at least it’s stack commitment space in virtual memory (the good news is that it’s virtual memory – normally that’ll just be space reserved in the paging file, not real memory).

Reduce the number of processes that your applet needs.  There’s rarely a good reason for you to require more than one process to do work.  About the only one I can think of is if you split functionality to increase the amount of code you have running at a high privilege level).  As an example of this, in Windows Vista, the audio stack runs in two separate services – the AudioSrv service and the AudioEndpointBuilder service.  This is because a very small part of the functionality in the audio engine has to do some operations that require LocalSystem access, but the rest of the audio stack can run just fine as LocalService.  So the AudioEndpointBuilder service contains the high privilege code and the AudioSrv service contains the rest.  If you feel you need to have a separate process to provide reliability (you run the code out-of-proc in case it crashes), windows Vista provides a cool new feature called the “restart manager“.  The restart manager allows the OS to restart your application if it crashes, reducing the need to run code out-of-proc.

Don’t forget that Windows is a multi-user system.  Some of your customers won’t want your applet, others will.  So make sure that the settings to enable/disable the applet are instanced on a per-user basis.  It’s really annoying when you right click on a notification area icon and see that the “disable this” menu is disabled because you’re running as a normal user (which is most users on Vista).  Whenever I see this, I know that the author of the applet didn’t consider the normal user case.

If you can target Vista only, consider reducing your thread and I/O priority.  If your applet is performing processing that’s not directly related to the user, use the new PROCESS_MODE_BACKGROUND_BEGIN option in the SetPriorityClass API to let the system know that your process should be treated as a low priority background process – that way your applet won’t preempt the user’s work.  You can also use the new FileIoPriorityHintInfo method of the SetFileInformationByHandle to let the OS to prioritize your I/Os to a handle below that of other user operations.


Next: Mitigations for updaters (no post tomorrow since I’m moving offices).

Comments (25)

  1. Anonymous says:

    On the restart manager: It is almost a no-brainer to not use it. Only Vista? Gee, I cannot imagine any ISV who could afford that…

    "make sure that there’s a way for the user to turn it off" That is not going to work. What incentive does a ISV have to provide that option?!? None, really. This is a classical game theory problem. There is a cost to do it the way you suggest it. The benefits of doing it properly are tiny, if you are alone doing it. Plus, any ISV doesn’t really get the benefits, rather the platform as a whole gets it, IF everyone does it. Basic economic theory tells you that you will always get the non-cooperative solution in such a situation, you are fighting a battle you cannot win. The way out is to recognise that a) MS is the only party that would really benefit if all ISVs did it properly (simply because the Windows platform would hopefully be known to not have all the crappy negative side effects of applets) and that therefore you guys need to get the incentives right for ISVs. What could that be? Simple, make it even LESS costly for an ISV to provide these options than not to. How could that be achieved? Something like Vista’s mobile applet window, maybe with an option to active and deactive per user services or something like that would be a good start. If you provide a prominent UI place for applets to plug into (sidebar might be another place, or even a new notification area), ISVs will want to be there. Then use that and only provide an API to get to that UI space that at the same time allows users to simple enable/disable such services. You can go on an ask ISVs forever to change their behaviour, but unless you understand the economics of this and act accordingly, nothing will change.

  2. Davidacoder: Actually it’s not that horrible to build stuff for XP and then light up additional functionality on Vista – Office does this, for example.  It does mean additional work, but it’s not the end of the world.

  3. Anonymous says:

    davidacoder makes a good point. It is about economics.

    There are many ISVs that work hard to make something difficult to disable, kill, change.

    Think all the crap^H^H^H^H applications that every time they run they hijack file formats, add themselves to autostart, to system try, to desktop, start menu, quick launch, explorer context menus, etc.

    This is a lot of work. They do it because *they want* to be "in your face," not because is easy.

  4. Anonymous says:

    Speaking of the audio service, don’t forget AudioDG.exe.  On my system it’s got a working set of 40 megs.

    Honestly, if a ‘craplet’ is taking up 4 megs or so of memory, I think (de-sensitized by all of the components in Vista), ‘Oh well’.

  5. If audiodg is taking up that much memory, you should check to see if an updated driver is available for your audio solution (or disable all system effects).  We’ve had reports of buggy audio drivers that have memory leaks causing this – on most machines I’ve looked at, audiodg consumes around 4M of RAM.

  6. Anonymous says:

    But if an ISV cares about reliability, it will care about reliability on Vista AND old Windowsversions. Following your suggestion would mean that the ISV should use Vista’s restart manager on Vista systems, and a homegrown solution on older versions. What is the incentive for an ISV to do that? The homegrown version has to be developed in any case, what does he gain from expending more dev time to also implement use of Vista’s restart manager? Why would he use it? There is no incentive at all in such a situation.

  7. Anonymous says:

    davidacoder That most likely means that MS should make restart manager available downlevel (i.e. on XP, since that is the only other platforms [yes I mean plural] that matter since every thing else is more or less EOL) Now the economic question is does MS benifit enough to do that in a way that is good for customers?

  8. charless, that ain’t gonna happen.  

    There’s no reason that an application can’t take advantage of the restart manager when running on Vista – Office somehow manages to take advantage of the restart manager when it’s running on Vista, and on previous OS versions, it doesn’t.

    When you run on Vista, new features and functionality light up, on previous OS releases, they don’t.

  9. Anonymous says:

    Larry, independent developers are in a different situation than Office. Unlike Microsoft, we don’t common up-level bosses that say we must take advantage of the new Vista features to prevent the company from looking like hypocrites. Our bosses look at the huge XP installed base and relatively slow uptake of Vista and say, "Make sure it works on XP and Vista, but only add Vista-specific features if it buys *us* something."

    It’s often easy to leverage Vista’s low-priority I/O with a few lines of code, but it’s another to completely retool the crapplet design and installation process to use the Vista scheduler or other functionality. That takes time, and time takes money, and time prevents shipping.

    I really like the Vista scheduler, it’s an undiscovered gem. To be realistic it wouldn’t even help if Microsoft back-ported it to XP at this point unless they also allowed third parties to ship it as a redist with their products since most systems wouldn’t have it installed. By the time all that happened it will be 2011 and XP will be fading fast.

  10. Dave, actually that’s not <i>quite</i> the way it worked – the reality is that our "common up-level boss" was Bill Gates (Office is in Jeff Raikes org, Windows was in Jim Allchin’s org, now in Kevin Johnson’s org).

    As I understand it (obviously, I’m not on the Office team, neither am I on the restart manager team), the Office team learned about the new features we were planning on Vista (the same way that our other customers did), realized that they were specifically designed to address certain pain points that customers (including Office) were feeling, and adopted them.

    It didn’t add a significant amount of complexity to their test matrix (they already had to test on Vista, this just meant that their Vista tests cases also included testing the restart functionality).

    I’m trying to be very clear about the Vista-specific functionality in these discussions.  The vast majority of the stuff I’m talking about works on OS’s as far back as Windows ME (some of the advice goes way back to NT 3.1).

    Even if you don’t adopt the Vista-specific functionality, the other recommendations are still valid.

  11. Anonymous says:

    Does anyone know of any important third party app that takes advantage of some new technology that is in Vista, i.e. lights it up as Office does it? Or has that happened when XP was introduced? Just curious, I honestly don’t know.  But none comes to mind, right now. I no major up besides Office does it, then that would suggest to me that their using it was a incentive that came from being in the same company with Windows 🙂

  12. Anonymous says:

    Here’s another rule I’d like added to your list – Be Hibernate-Aware. When I wake my notebook up from sleeping after an hour or so, there’s no problem. But if it’s been sleeping for a couple days, say, over the weekend, it takes a very long time to finally wake up due to all the hard drive activity. I had to disable the page file in fact to keep it from taking 3-5 minutes to wake up.

    I’m not 100% sure of the problem but it appears to be that every app in the system is doing its "hey, it’s been a while since I’ve done task x" routines. So maybe, Explorer is re-checking the Start Menu to figure out what to highlight, the Recycle Bin is clearing out files, every updater type applet is busy trying to get on the network to check for their updates, Google Desktop is refreshing its Gmail index, etc. All of which starts to happen instantly as soon as the machine starts up the processes again after waking up. Which causes a huge amount of hard drive activity, not good for a 4200 rpm notebook hard drive. Especially when all you want to do is check email real quick.

    Disabling the page file helped quite a bit for me. I tried killing as many applets as possible, keeping my drive and pagefile defragged, but nothing solved the 3-5 minute wake-up time until I killed the page file.

    Simple rule to be hibernate-aware: if it’s been > 60 seconds since your last update loop iteration, then the machine has probably been hibernated. Wait a random amount of time from 20 seconds to 5 minutes before doing whatever checks unless it’s absolutely necessary to do it immediately (like perhaps logging into IM). Auto-updaters do not fall into this category.

  13. Scott, that’s an interesting point.

    I don’t see why turning your paging file off helps the hibernate case, all you’re doing is forcing the system to keep all your code in memory (which means that the stuff you’re not using hurts the stuff that you are using).

    If you’re running XP, I suspect you’re seeing what we call "standby list erosion" (slava oaks talks about it here:, the good news is that Vista has logic to alleviate that problem.

  14. Anonymous says:

    > (no post tomorrow since I’m moving offices).

    (1) You mean the applets will let you move offices *before* they run?

    (2) You need to switch back from C# to C++.  Then you can just update a pointer instead of moving.

  15. Norman, I wish that moving offices was as easy as redirecting a pointer.  It’s a royal pain in the neck (you see, I have these extremely large and distressingly fragile lego models that have to be moved by hand)…

    Btw, I do all my real work in C++ 🙂

    Btw2: Daniel just opened up his new Lenovo x61 tablet (a present for taking honors algebra 2 over the summer), I was literally astonished at the amount of stuff that came preloaded on it (norton’s security suite, diskkeeper, office 12 (trial edition), the list was quite long).

  16. Anonymous says:

    Some people seem to be saying that, since "nobody wants to write Vista-only apps," Microsoft should never add another feature to the OS. That’s crazy talk. In the worst case, eventually Vista will be the minimum OS that you support and you’ll be glad that X years in the past some useful features were added that you can now take advantage of. In reality, people write code all the time which detects the OS and invokes new features where available, falling back on different behaviour where not.

    I know I do. In fact, both things apply now. I’ve dropped Win95 and NT4 support from the things I write and now I can use some of the nicer APIs in Windows 2000 (and Win98 and NT4) where before I either had to use a more primative API or have conditional code which used the new API where available (via GetProcAddress, stuff copied out of header files, conditional logic and other hassles) and the old API where not. Eventually I’ll be able to include the Vista APIs as standard and I’ll be glad they were added to Windows back in 2007.

  17. Anonymous says:

    I bought a Microsoft LifeCam VX6000 webcam for my Vista PC. It installs one service and another application which automatically runs in the background when the user logs in. The problem isn’t just that two processes are installed, nor that what they do isn’t very useful. The way they are written is really, really bad.

    Larry, before I continue, let me say: Feel free to moderate this post out of the blog comments. I don’t mean to bring it up in public and say "hey MS are as bad as everyone else" (you said it already and it doesn’t need saying; MS are a huge company with hundreds of developers of varying talent and experience and they’ll make mistakes like anyone else will). I just want to mention it to you in case you can have some influence on the responsible team, even if it’s just calling them names if you see them at lunch, in the hope that the shame will force them to do a better job. 🙂

    The service is MSCamSvc and whoever wrote it didn’t even bother to give it a proper name or description. As far as I can tell the service does nothing other than launch an application when the physical "phone/globe" button on top of the webcam is pushed. At least, I have stopped the service and set it to Manual startup for the last few months and that’s the only "downside" I’ve noticed so far. (I’ve never wanted to use that button anyway.)

    The application is vVX6000.exe and I have used Windows Defender to block it from running at startup. The only "downside" to preventing this helper app from running is that I can no longer use the feature which overlays backgrounds and animated images on the webcam in realtime. If I do want to use that feature then I can run vVX6000.exe manually, and then kill it afterwards. The backgrounds are cute and might be worth an extra process, except for what that process does 24/7… (I’ll get to that in a second.)

    Apart from those two largely useless features the webcam works absolutely perfectly when both the service and the helper app are not running. In the case of the helper app I don’t understand why it couldn’t be started on-demand when an application starts using the webcam.

    That isn’t the worst of it, though. The only reason I even noticed these two programs is that they *poll* the registry and filesystem every two seconds or so. They do this whether or not the webcam is in use. This spams the hell out of ProcMon logs, as you can imagine, and it can’t be good for the PC’s performance to have two do-nothing processes constantly active, loaded into memory that can’t be paged out, and hitting the filesystem/registry every 2 seconds. Whoever wrote them could really do with some Win32 lessons, in particular about wait handles and registry/filesystem change notification.

    Again, I stress, I’m not mentioning this to say "OMG MS suck!" and I don’t mind if you don’t publish this comment. I just thought it was particularly badly written and gratuitous software that you might be able to bug someone about, especially if it’s a pet hate of yours.

    Thanks for listening!


  18. Anonymous says:

    Regarding disabling the page file, doesn’t that explain exactly what I’m seeing? I’ve got 2 gigs of RAM on this thing, and haven’t gotten close to using it up. Even with a few copies of Dev Studio running and all the other assorted tools I use, still has plenty to go. I’ve noticed better performance in general from this, especially when restoring minimized apps. Which reminds me..

    I remember reading somewhere that when you minimize an app, the system will page it out either right away, or relatively quickly. Any memory pressure (from a hog like Outlook or Firefox) will flush read-only pages, probably most of which is code I would bet. Is that right, or at least close?

    So: consider if Outlook is set to check email every 30 minutes. You minimize it, surf a little, the system pages most of Outlook out, then hibernate for the weekend. On Monday, upon waking up, Outlook figures out it needs to check email, update RSS feeds, run filters, check appointments, basically pull everything back in again that got flushed before hibernate – the PST file, the network stack, all the millions of supporting DLL’s, etc. It does that the *instant* it gets any CPU time after restoring from hibernate. So it locks up the hard drive with seeks precisely when I need it to do one thing (such as do a quick Google Map search to find where the bar I’m going to in 5 minutes is). Add to that a bunch of applets and you (or at least I) have an unresponsive system because this poor little notebook hard drive just can’t keep up with all these simultaneous requests.

    Disabling the page file doesn’t fix the cache flush issue, but it does keep all the code in memory. I have this problem on Vista. In fact, I upgraded my notebook from XP in large part because I expected Vista to fix this horrible problem, which I’ve seen increasingly over the years from XP. It’s far worse than XP ever was, too. I never thought of disabling the page file on XP, but was forced to do it on Vista. There’s a couple apps that don’t work, they must use the page file (what was it…some memory mapping function that you could alloc backing store from the page file) but I’m not looking back.

    Am I the only one that has noticed this situation? It drives me absolutely nuts..

  19. Anonymous says:

    I can confirm Scott’s problem, I am on Vista, everything up to date, with a 7200 RPM disc, Thinkpad T60. Plain and simple terrible, I NEVER get good start up times when I had the machine in hibernate for a while.

  20. Anonymous says:

    First off (as always), reconsider your need for a notification area handler. Seriously consider if it’s

  21. Anonymous says:

    I… guess it shows that a lot of today’s hardware comes loaded with crapware? I mean, when a developer is paid to output as fast as possible a useless app, it will botch it up something fierce anyway…

    This may have come from a missed opportunity; for example, all those updaters would have fit much better in the Scheduled Task Manager: they wouldn’t have been running when unneeded, and still accomplished what they were set up to do. However, not only did the Scheduler not work very well initially, its interface was awkward and didn’t allow an installer to set it up interactively (or to prevent modification upon their updater from the user), which made it unattractive in a pure branding aspect and technically harder to support than a home-grown application.

    The only solution left was to embed it into the system so tightly that it wouldn’t move. And that became the norm – exit the Scheduler.

    Had it not been for that, all updaters could have run under a SINGLE constant process (as soon as you get two updaters, you win)

    About crappy apps hogging the tray: well, the only way to force editors to do a correct work would be to force a numeric signature of their apps – obtaining that signature would require that the app can be shut down for good. In the webcam example however, that would require signing the driver, the main manager application, and the ‘eye-candy’ feature app.

    That’s an area where I enjoy Free software: since the source code is readily available, programmers are forced by their ego to create proper code. This usually entails: reduced footprint, no more resources drawn than required, use currently installed libraries, ensure that it works solely in user space, provide correctly threaded and portable code.

    Moreover, cron and anacron allow intelligent task scheduling, while the hibernation model used on, say, Linux, requires the RAM and swap partition to be cleaned up before hibernation (the swap is emptied before being reused as memory dump) – meaning that any task an app may want to run at wakeup will take place in RAM.

  22. Anonymous says:

    As a senior developer at Microsoft, you often find yourself participating on a number of v-teams. One

  23. Anonymous says:

    In previous articles, I&#39;ve pointed out: Programmer Hubris – He&#39;s just not that into you Programmer

  24. Anonymous says:

    Interesting that you should mention this, I’ve just been in a debate with a programmer whose applet displays four small icons in the notification area. It takes 15MB of memory (and a pile of other system resources) to do this, because it includes everything but the kitchen sink as part of the program, even though the only part that’s actually used 99.9% of the time is the tiny fragment that handles the notification area (I would guess the working set isn’t larger than a few hundred kB).

    The response to any requests from users for a lite version is some variant on "it’s only 15MB, no-one will even notice it". Sigh.

  25. Anonymous says:

    After I posted my article on the SHAutoComplete , I mentioned it to one of my co-workers. His response

Skip to main content