When I open Indexing Options, it says:

4,317 items indexed Indexing in progress. Search results might not be complete during this time.

It's stuck at 4,317 though; no more items have been indexed. Worst of all, SearchIndexer.exe is taking up 100% CPU (well, 50%, but I have a dual core CPU; it's taking up all processing power it can). It is not causing hard drive activity though.

I tried clicking "Troubleshoot search and indexing" at the bottom of the Indexing Options window, but it couldn't find any problem.

I've also tried the repair registry key that several websites suggest; I change HKLM\SOFTWARE\Microsoft\Windows Search SetupCompletedSuccessfully to 0 and restarted the computer, and it apparently repaired because it flipped back to 1, but the same problem continues to occur.

It's reducing the battery life of my laptop and making it really hot so that my fans are running all the time. I've had to disable the Windows Search service. How can I fix this? Do I need to just flat-out reformat my computer?

I've tried rebuilding a couple times. There's nothing unusual about the locations I have to index, and I don't have any downloads in progress or anything like that. I don't see any reason why it stopped, and I noticed it much too late to do a system restore. At this point, I'm hoping someone will offer up some secret answer that will fix the problem, thus the bounty.

Another update:
I tried starting the service again, just to let it try yet again. It seemed okay at first (Indexing Options showed it operating at reduced speed due to user activity, and the number of files was going up). A while later I checked, and the service had stopped. Event viewer revealed some errors like this:

Log Name:      Application
Source:        Application Error
Date:          2/1/2010 7:34:23 PM
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      ricky-win7
Faulting application name: SearchIndexer.exe, version: 7.0.7600.16385, time stamp: 0x4a5bcdd0
Faulting module name: NLSData0007.dll, version: 6.1.7600.16385, time stamp: 0x4a5bda88
Exception code: 0xc0000005
Fault offset: 0x002141ba
Faulting process id: 0x13a0
Faulting application start time: 0x01caa39f2a70ec02
Faulting application path: C:\Windows\system32\SearchIndexer.exe
Faulting module path: C:\Windows\System32\NLSData0007.dll
Report Id: b4f7a7ae-0f92-11df-87fc-e5d65d8794c2
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    <Provider Name="Application Error" />
    <EventID Qualifiers="0">1000</EventID>
    <TimeCreated SystemTime="2010-02-02T00:34:23.000000000Z" />
    <Security />

If you are having the same error and arrived here from a Google search, please comment or add an answer detailing your progress on this, if any...

  • 4
    By the way... Does anyone know a way to figure out what this magical 4,317th item is? I would love to know if there is just one malformed file jamming the entire system. – Ricket Feb 1 '10 at 7:18
  • You can open the Windows.edb file using some somewhere called ESEDatabaseView here: nirsoft.net/utils/ese_database_view.html – user2924019 May 5 '16 at 16:12

I think you could be correct when you say that there's a corrupted file that causes it to hang. A crude way of trying to identify the file is to go the files tab and turn off half the files types from being indexed. Let it run. Either it completes or it stops. If it stops, turn off half again. If it completes, you know the bad file type is in the other half. Doing this should allow you to identify the bad file type.

Also, look through the file list that's indexed. File types have different search providers, like HTML, plain text and so on. Are there any that look out of place, that might have been installed by some third party application?

Another idea is let the search hang on the 4,317th file. Then run a command prompt. Type

CD c:\
DIR /s /TA /O-D >c:\newt.txt

This will create a file named newt.txt that will hold all of the files and the last time they were accessed. Accessed, meaning read, not modified. You'll have to search through the file with a file editor but look for the last several files that were modified. If we're in luck, your bad file will be in there. Good luck!

  • Nice tip (the second idea). Don't the indexer keep some sort of log of files indexed somewhere? It could let us see the last file succesfully indexed, and maybe get a clue this way. – mtone Feb 2 '10 at 20:57
  • @mtone - Is it possible to index one folder at a time? It would narrow down the search. – Nifle Feb 4 '10 at 0:14
  • @Nifle - yes, it would also be a reasonble investigation to reduce the number of folders indexed. Under the start menu, type "indexing" and click on indexing options. That panel lists the locations you are indexing. – Knox Feb 4 '10 at 18:24
  • @Knox +1 for the first Idea. You are suggesting an elimination [binary] search. And if you modify it with your understanding of likelihood of defect, and limit the indexing to those first, then you can get much better than O(log2 N) speedup. – ElderDelp Mar 16 '18 at 19:07

I found this information at Technet forums

It seems to be a known bug:

  1. PC has two (or multiple) drives or partitions

  2. User profiles and Windows are located on the first drive or partition (assume drive letter C:)

  3. Second drive or partition has more available free disk space than the first (assume drive letter D:)

  4. A ConfigMgr 2007 OSD Refresh Task Sequence that uses USMT 4 with hardlinking is run on the PC Then the Capture User Files and Settings"/"Capture User State" task will succeed, but the "Restore User State"/"Restore User Files and Settings" task will fail.


To resolve the problem, the variable OSDStateStorePath has to be changed from its default value. When using MDT 2010/MDT 2010 Update 1 integration, the variable has to be redefined after it has been set by the ztiuserstate.wsf script in the "Determine Local or Remote UserState" task.

To ensure that the State Store is saved to the same drive/partition where Windows is installed and the user profiles are located, the environment variable SystemDrive can be used as part of the path that defines the variable OSDStateStorePath.

If MDT 2010/MDT 2010 Update 1 integration is not being used, the "Set Task Sequence Variable" task that sets the variable OSDStateStorePath needs to be modified:

  1. In the ConfigMgr 2007 Admin console, navigate to the Computer Management --> Operating System Deployment --> Task Sequences node.

  2. Right click on the affected Task Sequence and choose "Edit".

  3. Click on the Set Local State Location task. Ensure that the task is a Set Task Sequence Variable task that sets the variable OSDStateStorePath.

Next to the Value: text field, change it from %_SMSTSUserStatePath% to %SystemDrive%\UserState

  1. Click on the "OK" or "Apply" button to save the task sequence. If the "Set Local State Location" task does not exist, then look for a "Set Task Sequence Variable" task that sets the variable OSDStateStorePath, and then make the changes above. If using MDT 2010/MDT 2010 Update 1 integration, then a new "Set Task Sequence Variable" task needs to be added after the "Determine Local or Remote UserState" task that redefines the variable OSDStateStorePath:

  2. In the ConfigMgr 2007 Admin console, navigate to the Computer Management --> Operating System Deployment --> Task Sequences node.

  3. Right click on the affected Task Sequence and choose "Edit".

  4. Click on the "Determine Local or Remote UserState" task and then go to "Add" --> "General" --> "Set Task Sequence Variable". This should create a "Set Task Sequence Variable" task after "Determine Local or Remote UserState" task but before the "Request State Store" task.

  5. In the newly created "Set Task Sequence Variable Task":

    • Next to the Name: text box, enter in: Set Local State Location
    • Next to the Task Sequence Variable: text box, enter in OSDStateStorePath
    • Next to the Value: text box, enter in: %SystemDrive%\StateStore
  6. Click on the "OK" or "Apply" button to save the task sequence.

If in Step 3 the task "Determine Local or Remote UserState" does not exist or has been renamed, look for the "Run Command Line" task that runs the script ztiuserstate.wsf, and then follow the above steps.


First things first, try rebuilding your index. Also, exclude from indexing any folders with temporary/uncompleted downloads. Unfinished files are by definition corrupted and could hang the process. Video/audio codecs could also possibly hang if the indexing looks up metadata in them.

alt text

  • Can you elaborate on the metadata comment? If something, somewhere is jamming this thing up, maybe it will help me think of it. – Ricket Feb 1 '10 at 7:17
  • Indexing tries to to obtain metadata by looking into files. Some types of files, such as AVI movie files necessitate codecs (or container loaders, often refered to as codecs as well) to open these files and get resolution, length, etc. That codec could hang if a file is corrupted. That said, I have not encountered the problem so far in Windows 7, but in XP it used to be a common problem. – mtone Feb 1 '10 at 15:59

My search was stuck due to a bad Outlook.pst file. I ran the pst repair utility SCANPST.EXE found in the same directory as the Outlook 2007 executable (C:\Program Files (x86)\Microsoft Office\Office12 on my Windows 7 x64 machine.)

enter image description here

  • 1
    File is named SCANPST.EXE – M. Dudley Jul 25 '12 at 15:18

Have you verified that your hard drive isn't dying?

Right-click on the drive, open the Properties dialog, go to the Tools tab, and perform an error check (with bad sector scanning).

  • yes, very good idea to ensure the basics are working right. Also check the event log for system errors. – Knox Feb 4 '10 at 13:24

One of the questions asked here was about how to see whether the SearchIndexer.exe is blocked, faulting or hanging, or whether there is still progress. Also, it would be nice to see what file is currently being indexed.

Here's a way to find out.

Microsoft does not readily give you tools for viewing this, the log files created during search, like MSS.log (later copied and changed in other names, and then deleted) are binary files and cannot be read unless with special tools.

Another alternative I tried to find out whether it was hanging on a single file or not was to fie up SysInternal's Process Monitor. I set the filter as follows:

  • include process SearchProtocolHost.exe (note: not SearchIndexer.exe) ,
  • include event type File System,
  • exclude anything on the C:\Windows and C:\ProgramData directories,
  • and/or include the directories you are actually indexing,
  • optionally set Operation to ReadFile.
  • click Apply or OK and then click the Capture button top-left.

The resulting event view gives you all ReadFile operations (and some others) that are currently being read by the Microsoft Search Index service.

It should be a long list of ReadFile operations and the files currently being indexed are in the Path column. The Result column should show SUCCESS (if not, there's your issue) and the Detail column should continuously show a different offset (if not, it is looping, and that is again a possible hint for the cause of your issue).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.