Windows Search Engine Processes

The new Windows Search engine in Windows 7 and Windows Vista is based on the MSSearch indexing and search engine developed previously for SQL Server, SharePoint Portal Server, Microsoft Office SharePoint Server, and other Microsoft products. The new Windows Search engine replaces the Indexing Service (Cisvc.exe) used in earlier Windows platforms, including Windows XP and Windows Server 2003.

The Windows Search engine logically consists of the following four processes:

• Indexer process The indexer process (SearchIndexer.exe) is the main feature of the Windows Search engine and is responsible for core indexing and querying activity on the system. This process is implemented as a Windows service named Windows Search service (WSearch) and is exposed for management in the shell through the Service Control Manager (Services.msc). This service runs in the context of the LocalSystem account but has all privileges removed except for the following two privileges:
  • SE_BACKUP_PRIVILEGE This privilege allows the service to read every file on the system so that it can be indexed.
  • SE_MANAGE_VOLUME_PRIVILEGE This privilege allows the service to interact with the NTFS change journal.
• System-wide Protocol Host The system-wide Protocol Host (SearchProtocolHost. exe) is a separate process that hosts protocol handlers to isolate them from the main indexer process. Protocol handlers are plug-ins assessing different stores, retrieving documents, and pushing the information to the SearchFilterHost process for filtering. The system-wide Protocol Host runs within the same LocalSystem context as the main indexer process. This security context is needed because the Protocol Host requires access to all files on the system. The system-wide Protocol Host also supports crossuser notifications and enumeration of per-computer data stores such as the local file system.
• Per-user Protocol Host The per-user Protocol Host (also SearchProtocolHost.exe) is another separate process that hosts protocol handlers to isolate them from the main indexer process. The difference between this process and the system-wide Protocol Host is that this process runs within the security context of the logged-on user. (If two users are logged on to the computer using Fast User Switching, it is likely that two per-user Protocol Hosts will be running.) A per-user Protocol Host is necessary because some data stores must be accessed using the credentials of the logged-on user to be indexed. Examples of such stores include Outlook e-mail (using MAPI), the CSC, and remote file shares.
• Search Filter Host process This process (which runs as SearchFilterHost.exe) hosts IFilters, which are used to extract text from files and other items. IFilters are hosted within a separate process instead of within the main indexer process to protect the Windows Search service from possible crashes and ensure the stability and security of the indexing engine. This process is needed because, although many IFilters are written by Microsoft, other IFilters may be written by third-party vendors and are therefore considered to be untrusted code. Hosting IFilters within a separate process (such as a filtering host) that has very restricted permissions (such as a restricted token) provides a level of isolation that protects the main indexer process if an IFilter crashes. The indexer process runs a single instance of SearchFilterProcess.exe, and this process holds all IFilter parsing documents that come from the system-wide and per-user SearchProtocolHost processes. This Search Filter Host process only reads streams of content, runs IFilters, and returns text to the indexer process.

In normal operation, each of these processes starts immediately after Windows boots and the desktop appears. The main indexer process (SearchIndexer.exe) is the only one that always continues to run, however-the other processes may or may not be running, depending on the immediate needs of the Windows Search engine. The main indexer process uses the standard service control mechanism (Service Control Manager) to detect when the service is not running and restart itself. The conditions for restarting the service can be found on the Recovery tab of the Windows Search Service Properties dialog box, which can be viewed using the Services console. These restart conditions are as follows:

• Restart the service immediately after the first failure occurs.
• Restart the service immediately after the second failure occurs.
• Take no action after subsequent failures occur.
• Reset the failure count after 1 day.

Additional applications can also attempt to restart the indexer if it stops. For example, Windows Explorer does this whenever you attempt to execute a search from either the Start menu or Search Explorer. You can see this by stopping the Windows Search service and then typing in the Start menu or the Explorer search box. To prevent Windows Explorer or any other application from restarting the Windows Search service, you must disable the service, not just stop it.