By now every company should have got the memo from Microsoft regarding limiting or eliminating reboot requirements of software. Most of the security products today (such as security suites that package personal firewall, antivirus, antispyware, email filtering etc etc) involve kernel-mode drivers and thus may need to reboot at install so they can start from a known point of boot. By the same token, reboot may be necessary when uninstalling such software.
One of the reasons reboot may become necessary during uninstall is because of presence of legacy file system filters. Legacy file system filters (such as anti-virus filter) generally cannot be unloaded safely in the NT layered device model and therefore are inactive only after the reboot. A mini-filter model was introduced in Windows XP and later supported by popular demand on Windows 2000 SP4 with Update Rollup 1. In the new model, there is a file system filter manager (implemented in fltmgr.sys) which manages and oversees the mini-filters. One of the benefits of this model is that filters now can be unloaded (and loaded) without reboot.
This is all good, but not all companies have rewritten their drivers to the mini-filter model because it is a significant undertaking and companies perhaps do not see value in the long-term benefits for one reason or the other. Besides it is not like the legacy model is going away, in fact the filter manager itself is a legacy filter.
Another reason why reboot may be necessary during uninstall is because there is API hooking in kernel-mode. API hooking, is sometimes the only way to add some security related pre or post processing around commonly (or uncommonly) used APIs on the system (such as when processes are being created via Win32 API CreateProcess, or when a keyboard hook is being installed by Win32 API SetWindowsHook so on and so forth). Although API hooking can be done in user-mode [and has been made difficult in 64-bit platforms by kernel patch protection], many security products in market today have some kind of kernel-mode hooking in place to realize security functionality because it is just a better way to do than doing it in user-mode. The downside of this however is that once the hooks are in place, there is no way to safely remove them during uninstall, and therefore reboot is the only way to get the machine back to original state of affairs.
Now with all the pressure (Microsoft logo requirements, PMs screaming enterprise customers do not want to reboot, reboot is bad and wrong, you will hear all kinds of reasons) of not prompting for a reboot, software writers have removed reboot prompts just not to look bad even when uninstallation is guaranteed to be incomplete without a reboot.
Case in point, ZoneAlarm from Checkpoint. I installed the ZoneAlarm Suite 7.1.078 on one of my Vista hosts and it prompted for a reboot at the end of installation, but when uninstalling, there was no prompt for reboot. Even after uninstallation was complete it had its hook driver (vsdatant.sys) and Kaspersky drivers (packaged along with for anti-virus and other functionality) kl1.sys and klif.sys loaded and running. Even puzzling was, the Kaspersky drivers were not deleted from disk.Neither were the driver entries for them were removed from under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services. With those registry entries in place and the sys files in place, and since there seemed to be no removal entry for these two files upon reboot, these two drivers ended up being active even after reboot. Interestingly if one runs the suite installer again after uninstalling (but before rebooting), it fails with the following message.
I do not like products that do not uninstall clean. In fact if something does not uninstall clean, I presume they are some kind of malware that wants to leave behind some active components even after uninstall.
Any software and especially security software, should be honest about whether it is uninstalled or not. And sometimes, reboot, as much as we hate it for one reason or the other, is necessary. Users should not be left with machines in strange state where performance impact of security processing, system reliability (users uninstalling on the belief that product makes the machine unreliable), subtle side-effects (users uninstalling because an application does not work any more) or bug in software that just lied about uninstall, can affect computing experience. Also users may choose to install other potentially incompatible software or the same product again believing that the uninstall completed with perhaps undesirable or unexpected behaviour.
Now I am sure, there are products that are rebootophobic during install, in which case, all the security may not be in place giving user false sense of security. If software is rebootophobic during upgrade, all the updates may not be in place until you reboot and that could include security updates, definition updates so on and so forth. And that means the end user is again at risk until the next reboot.
If you know, the product has a legacy file system filter or a hook driver, you will need to reboot at least during uninstall and driver upgrades. There is no way around it.
Be wary, if a security product with multiple drivers, does not prompt for reboot during uninstallation (or installation). I would.
