Windows 7: Search indexing is stuck

▲
14
▼

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?

Update:
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
Description:
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">
  <System>
    <Provider Name="Application Error" />
    <EventID Qualifiers="0">1000</EventID>
    <Level>2</Level>
    <Task>100</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2010-02-02T00:34:23.000000000Z" />
    <EventRecordID>10689</EventRecordID>
    <Channel>Application</Channel>
    <Computer>ricky-win7</Computer>
    <Security />
  </System>
  <EventData>
    <Data>SearchIndexer.exe</Data>
    <Data>7.0.7600.16385</Data>
    <Data>4a5bcdd0</Data>
    <Data>NLSData0007.dll</Data>
    <Data>6.1.7600.16385</Data>
    <Data>4a5bda88</Data>
    <Data>c0000005</Data>
    <Data>002141ba</Data>
    <Data>13a0</Data>
    <Data>01caa39f2a70ec02</Data>
    <Data>C:\Windows\system32\SearchIndexer.exe</Data>
    <Data>C:\Windows\System32\NLSData0007.dll</Data>
    <Data>b4f7a7ae-0f92-11df-87fc-e5d65d8794c2</Data>
  </EventData>
</Event>

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...

windows-7
windows-search
asked on Super User Jan 27, 2010 by Ricket • edited Feb 2, 2010 by Ricket

6 Answers

▲
8
▼

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!

answered on Super User Feb 2, 2010 by Knox • edited Feb 3, 2010 by Knox
▲
4
▼

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

answered on Super User Jan 28, 2010 by mtone • edited Sep 20, 2011 by Gaff
▲
4
▼

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

answered on Super User Mar 15, 2010 by glenviewjeff • edited Jul 25, 2012 by glenviewjeff
▲
4
▼

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.

Resolution

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.

answered on Super User May 14, 2011 by Richard Webb • edited May 14, 2011 by Sathyajith Bhat
▲
2
▼

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).

answered on Super User Feb 3, 2010 by Mr Fooz
▲
2
▼

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).

answered on Super User Jul 16, 2014 by Abel

User contributions licensed under CC BY-SA 3.0