First off (as always), reconsider your need for a notification area handler. Seriously consider if it’s appropriate for your application to have a notification area handler. Do you really believe that it provides sufficient functionality to justify taking up limited notification area real-estate? Really?
From what I’ve seen, some notification area handlers are quite well thought out and provide easy access to useful information or commonly accessed functionality (the volume, clock, taskmgr, “safely remove hardware” and RSS Bandit are ones come to mind). Some have questionable value (the network and outlook handlers come to mind), some just don’t seem to make sense at all (Quicktime and handlers like the various display driver and printer control panel notification area handlers). After all, do think that your customers really need to know how much ink remains in their printer all the time?
As I’ve mentioned in earlier articles, you should always have a mechanism for disabling your notification area handlers – it’s just polite (and if you don’t, your customer’s are going to find other ways of disabling your notification area handlers). Since you’re building a mechanism to disable your notification area handler, why not specify it as a checkbox in your installer? That way your customer never gets annoyed in the first place. In addition (and I’ve also mentioned this before), make sure that your notification area handler is instanced on a per-user basis. That way you (a) don’t require elevation to disable your notification area handler, and (b) you let the various users of the computer make a choice – some may choose to use your applet, others may not.
If you’ve decided that you MUST have a notification area handler, then why chew up an entire process to handle it? Windows offers a number of mechanisms to let you reduce the impact of your handler (it doesn’t remove the impact, just reduces it). For instance, you can use the task scheduler (mentioned earlier in my post about updaters) facility to launch your notification handler upon user logon – that provides a centrally manageable interface to allow for task control. On Vista, you can define your task as firing a COM handler, in which case your applet gets launched in a hosting process – that means that instead of having a dedicated process, you live in a process that’s shared with other jobs (including other notification area handlers).
One final thing about notification area handlers: If you don’t have anything to say, shut up :)! People get really annoyed by notification area icons, one way to reduce their ire is to simply not register an icon unless you have something to say. You can see the effect of this with Windows Defender – they only insert their notification area icon if they need to alert the user, otherwise they’re mute. There’s a huge caveat with this though: adopting this behavior can have unintended consequences. When the Defender team adopted this behavior (only showing the icon if there was a problem), they received a flurry of complaints from users because they felt that if the icon wasn’t present, defender somehow wasn’t working. As a result of this, the defender team added an option (off by default) to add their icon in the notification area all the time. Personally, I think that people believe this way because they’ve been conditioned by poorly written notification area handlers so that they believe they’re not protected unless they see the little icon, even though the icon has nothing to do with their protection level.
Next: Mitigations for services.
 As always, please remember my definition of crap: “Crap is defined as stuff I don’t want running on my machine” – you may very well disagree with my opinions about the relative usefulness of the various applets I’ve listed above.