FAQ: Why does WDS / Windows Vista use so many processes?
The three processes used by the Windows Search service are SearchIndexer.exe, SearchProtocolHost.exe, and SearchFilterHost.exe. Sometimes you may even see multiple instances of the latter two running simultaneously (especially if multiple users are logged in).
So why are they divided up in this way? To find out, let’s look at what each of the processes does.
This process runs as a system service under the SYSTEM account. It is responsible for maintaining the index, servicing queries, as well as deciding what to crawl and when.
This process sometimes runs under the SYSTEM account, and other times runs in the context of the current user. It hosts a Protocol Handler responsible for enumerating items in a specific store (such as the File System, Outlook, UNC shares, Lotus, etc).
Why is it seperate?
Access – Sometimes it needs to run in the context of the SYSTEM account (ie. to index the filesystem, even when a user is not logged in). Other times it needs to run in the context of the user, so that it can access data that is ACL’d for that user (network shares, Offline files) or accessed via a program the user is running (Outlook, Thunderbird).
Reliability – If a protocol handler, which may be written by a third-party, crashes – it will not crash the indexer itself. This reduces the risk of index corruption, and ensures that you can still issue queries even if a protocol handler crashes or hangs.
Security – Isolating code that interacts with possibly untrusted data stores can mitigate vulnerabilities in said code.
This process hosts the actual IFilters. These filters are responsible for processing individual items, such as files, in a data store.
Why is it seperate?
Security – This process is tightly locked down. For example, it cannot even read the filesystem. It runs with reduced privileges (kind of like Protected Mode IE). Why is this important? Well think back to the WMF file vulnerability a year or so ago. Google Desktop Search would trigger the vulnerability whenever it indexed one of those such files. If you received it as an e-mail attachment, you would have a 0-click attack because they don’t sandbox the indexing process. This wasn’t a problem for WDS users because we have always isolated filtering to a seperate locked-down process.
Reliability – Same as with the Protocol Handlers. IFilters are very often third-party code, and may be subjected to corrupted files. Keeping them seperated improves robustness to crashes / hangs in third-party code or when dealing with corrupted data.